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 <andres@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
