On 14 October 2015 14:03, Kyotaro HORIGUCHI: >Subject: Re: [HACKERS] Dangling Client Backend Process > >At Wed, 14 Oct 2015 11:08:37 +0530, Amit Kapila <amit.kapil...@gmail.com> >wrote in ><CAA4eK1L8SGWymhXF+yDpxiyA2ARCiEgQ88XsLhEvJba3Fh_F=q...@mail.gmail.com> >> On Tue, Oct 13, 2015 at 3:54 PM, Rajeev rastogi >> <rajeev.rast...@huawei.com> >> wrote: >> > If we add the event WL_POSTMASTER_DEATH also, client backend process >> > handling will become same as other backend process. So postmaster >> > death can be detected in the same way. >> > >> > But I am not sure if WL_POSTMASTER_DEATH event was not added >> > intentionally for some reason. Please confirm. >> > >> > Also is it OK to add this even handling in generic path of Libpq? >> > >> > Please let me know if I am missing something? >> > >> > >> I feel this is worth investigation, example for what kind of cases >> libpq is used for non-blocking sockets, because for such cases above >> idea will not work. > >Blocking mode of a port is changed using socket_set_nonblocking(). I >found two points that the function is called with true. >pq_getbyte_if_available() and socket_flush_if_writable(). They seems to >be used only in walsender *so far*.
Yes and in that case I assume the proposed solution will work in all cases. >> Here, I think the bigger point is that, Tom was not in favour of this >> proposal (making backends exit on postmaster death ) at that time, not >> sure whether he has changed his mind. >If I recall correctly, he concerned about killing the backends running >transactions which could be saved. I have a sympathy with the opinion. >But also think it reasonable to kill all backends immediately so that >new postmaster can run... Yes it will be really helpful to know the earlier reason for "not making backend exit on postmaster death". Please let me know if there is any thread, which I can refer to find the same. IMHO there could be below major issues, if we don't kill client backend process on postmaster death: 1. Postmaster cannot be re-started again as pointed by Kyotaro and Andres Also. 2. If from existing client session, we try to do some operation which has dependency with backend process, then that operation will either fail or may lead to undefined behavior sometime. 3. Also unintentionally all operation done by application will not be checkpointed and also will not be flushed by bgworker. 4. Replicating of WAL to standby will be stopped and if synchronous standby is configured then command from master will be hanged. Thanks and Regards, Kumar Rajeev Rastogi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
