pg_ctl stop -m fast after -m smart
"pg_ctl stop -m smart" will wait for all connections are disconnected and
"pg_ctl stop -m fast" will disconnect all connections forcibly.
But "fast" after "smart" also wait for disconnections.
Can we change the behavior that "fast" overwrites "smart" mode?
I'd like to achieve the following sequence:
$ pg_ctl stop
$ (found some connections remain)
$ [Ctrl+C]
$ pg_ctl stop -m fast
$ (force disconnect and stop server safely)
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center
Hi,
On Fri, Aug 7, 2009 at 10:31 AM, Itagaki
Takahiro<itagaki.takahiro@oss.ntt.co.jp> wrote:
"pg_ctl stop -m smart" will wait for all connections are disconnected and
"pg_ctl stop -m fast" will disconnect all connections forcibly.
But "fast" after "smart" also wait for disconnections.Can we change the behavior that "fast" overwrites "smart" mode?
+1. This behavior was supported in 8.2 or before, but broken in 8.3.
Here is the patch. This should be backported to 8.3 and 8.4.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
Attachments:
fast_shutdown.patchapplication/octet-stream; name=fast_shutdown.patchDownload+1-0
Fujii Masao wrote:
On Fri, Aug 7, 2009 at 10:31 AM, Itagaki
Takahiro<itagaki.takahiro@oss.ntt.co.jp> wrote:"pg_ctl stop -m smart" will wait for all connections are disconnected and
"pg_ctl stop -m fast" will disconnect all connections forcibly.
But "fast" after "smart" also wait for disconnections.Can we change the behavior that "fast" overwrites "smart" mode?
+1. This behavior was supported in 8.2 or before, but broken in 8.3.
Here is the patch. This should be backported to 8.3 and 8.4.
Thanks, applied.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Fujii Masao <masao.fujii@gmail.com> writes:
Takahiro<itagaki.takahiro@oss.ntt.co.jp> wrote:
Can we change the behavior that "fast" overwrites "smart" mode?
+1. This behavior was supported in 8.2 or before, but broken in 8.3.
Here is the patch. This should be backported to 8.3 and 8.4.
I think this was my fault :-(. Thanks for the fix.
regards, tom lane