On Fri, Mar 18, 2011 at 10:25 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Mar 8, 2011 at 7:05 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> * Smart shutdown >> Smart shutdown should wait for all the waiting backends to be acked, and >> should not cause them to forcibly exit. But this leads shutdown to get stuck >> infinitely if there is no walsender at that time. To enable them to be acked >> even in that situation, we need to change postmaster so that it accepts the >> replication connection even during smart shutdown (until we reach >> PM_SHUTDOWN_2 state). Postmaster has already accepted the superuser >> connection to cancel backup during smart shutdown. So I don't think that >> the idea to accept the replication connection during smart shutdown is so >> ugly. >> >> * Fast shutdown >> I agree with you about fast shutdown. Fast shutdown should cause all the >> backends including waiting ones to exit immediately. At that time, the >> non-acked backend should not return the success, according to the >> definition of sync rep. So we need to change a backend so that it gets rid >> of itself from the waiting queue and exits before returning the success, >> when it receives SIGTERM. This change leads the waiting backends to >> do the same even when pg_terminate_backend is called. But since >> they've not been acked yet, it seems to be reasonable to prevent them >> from returning the COMMIT. >> >> Comments? I'll create the patch barring objection. > > The fast smart shutdown part of this problem has been addressed. The
Ugh. I mean "the fast shutdown", of course, not "the fast smart shutdown". Anyway, point is: fast shutdown now OK smart shutdown still not OK do you want to write a patch? :-) > smart shutdown case still needs work, and I think the consensus was > that your proposal above was the best way to go with it. > > Do you still want to work up a patch for this? If so, I can review. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
