On Tuesday, September 04, 2012 12:11:28 PM Amit Kapila wrote: > On Tuesday, September 04, 2012 11:00 AM Andres Freund wrote: > > On Tuesday, September 04, 2012 06:20:59 AM Tom Lane wrote: > > Andres Freund <and...@2ndquadrant.com> writes: > >> > I can see why that would be nice, but is it really realistic? Don't we > >> > expect some more diligence in applications using this against letting > >> > such a child continue to run after ctrl-c/SIGTERMing e.g. pg_dump in > >> > comparison to closing a normal database connection? > >> > >> Er, what? If you kill the client, the child postgres will see > >> connection closure and will shut down. I already tested that with the > >> POC patch, it worked fine. > > > > Well, but that will make scripting harder because you cannot start > > another single backend pg_dump before the old backend noticed it, > > checkpointed and shut down. > > But isn't that behavior will be similar when currently server is shutting > down due to CTRL-C, and at that time new clients will not be allowed to > connect. As this new interface is an approach similar to embedded database > where first API (StartServer) or at connect time it starts database and > the other connection might not be allowed during shutdown state. I don't find that a convincing comparison. Normally don't need to shutdown the server between two pg_dump commands. Which very well might be scripted.
Especially as for now, without a background writer/checkpointer writing stuff beforehand, the shutdown checkpoint won't be fast. IO isn't unlikely if youre doing a pg_dump because of hint bits... Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
