Re: Dangling Client Backend Process

At Wed, 14 Oct 2015 11:08:37 +0530, Amit Kapila <amit.kapila16@gmail.com> wrote in
<CAA4eK1L8SGWymhXF+yDpxiyA2ARCiEgQ88XsLhEvJba3Fh_F=Q@mail.gmail.com>
> On Tue, Oct 13, 2015 at 3:54 PM, Rajeev rastogi <rajeev.rastogi@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