Thread: 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
Attachment
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