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*. > 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... regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
