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...


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:

Reply via email to