From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Petr Jelinek <petr(at)2ndquadrant(dot)com>, Shay Rojansky <roji(at)roji(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Some 9.5beta2 backend processes not terminating properly? |
Date: | 2016-01-02 15:20:58 |
Message-ID: | 20160102152058.g4vrlarute2vrmgz@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-01-02 15:40:03 +0100, Andres Freund wrote:
> I wonder if the following is the problem: The docs for WSAEventSelect()
> says:
> "Having successfully recorded the occurrence of the network event (by
> setting the corresponding bit in the internal network event record) and
> signaled the associated event object, no further actions are taken for
> that network event until the application makes the function call that
> implicitly reenables the setting of that network event and signaling of
> the associated event object."
> and also notes specifically for FD_CLOSE that there's no re-enabling
> functions.
>
> See
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms741576%28v=vs.85%29.aspx
> which goes on to talk about some level triggered events (FD_READ, ...)
> and others being edge triggered. It's not clear to me from that whether
> FD_CLOSE is supposed to be edge or level triggered.
>
> If FD_CLOSE is indeed edge and not level triggered - which imo would be
> supremely insane - we'd be in trouble. It'd explain why some failures
> are noticed and others not.
I found a few more resources confirming that FD_CLOSE is edge
triggered. Which probably doesn't just make our code buggy when waiting
twice on the same socket, but probably also makes it very timing
dependent: As the event is only triggered when the close actually occurs
it's possible that we don't have any event associated with that socket:
We only do so for shorts amount of time in WaitLatchOrSocket() and
pgwin32_waitforsinglesocket().
A bit of searching around brought up that we saw issues around this
before:
http://www.postgresql.org/message-id/4351.1336927207@sss.pgh.pa.us
I really right now can see only two somewhat surgical fixes:
1) We do a nonblocking or select() *after* registering our events. Both
in WaitLatchOrSocket() and waitforsinglesocket. Since select/poll are
explicitly level triggered, that should make us notice any events we
might have missed. select() appears to have been available for a fair
while.
2) We explicitly shutdown(SD_BOTH) the socket whenever we get a FD_CLOSE
object. I *think* this should trigger errors in WSArecv, WSAEventSelect
et al. Doesn't solve the problem that we might miss important events
though.
Given 2) isn't a complete fix and I can't find reliable documentation
since when shutdown() is supported I'm inclined to go with 1).
Better ideas?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-01-02 16:14:40 | Re: Some 9.5beta2 backend processes not terminating properly? |
Previous Message | Andreas Seltenreich | 2016-01-02 15:06:28 | Re: [sqlsmith] Failing assertions in spgtextproc.c |