Re: Proof of concept: standalone backend with full FE/BE protocol - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Proof of concept: standalone backend with full FE/BE protocol
Date
Msg-id 006201cd8a85$a6fca0f0$f4f5e2d0$@kapila@huawei.com
Whole thread Raw
In response to Re: Proof of concept: standalone backend with full FE/BE protocol  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Proof of concept: standalone backend with full FE/BE protocol  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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
clientswill 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.

With Regards,
Amit Kapila.





pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Cascading replication and recovery_target_timeline='latest'
Next
From: "Kevin Grittner"
Date:
Subject: Re: Multiple setup steps for isolation tests