> Analyzing locking state, lock occurs when backend wants to send
> data to stat collector. So state is:
> backend waits FD_WRITE event, stat collector waits FD_READ.
>
> I suspect follow sequence of events in backend:
> 0 Let us work only with one socket, and socket associated with
> statically
> defined event object in pgwin32_waitforsinglesocket.
> 1. pgwin32_send:WSASend fails with WSAEWOULDBLOCK ( or its
> equivalent ) 2. socket s becomes writable and Windows signals event
> defined statically
> in pgwin32_waitforsinglesocket.
> 3. pgwin32_waitforsinglesocket(): ResetEvent resets event 4.
> pgwin32_waitforsinglesocket(): WaitForMultipleObjectsEx waits
> indefinitely...
>
>
> If I'm right, it's needed to move ResetEvent after
> WaitForMultipleObjectsEx. But comment in pgwin32_select() says that
> we should send something before test socket for FD_WRITE.
> pgwin32_send calls WSASend before pgwin32_waitforsinglesocket(),
> but there is a call of pgwin32_waitforsinglesocket in libpq/be-
> secure.c. So, attached patch adds call of WSASend with void buffer.
Hmm. Not entirely sure. These are all in the SSL codepath. Are you using
SSL on the machine? Does the problem go away if you don't? (I was
thinking SSL always attempts to write data first, but then fails, at
which point this code is fine. You only need to attempt a send at it if
you didn't try that before)
The normal way is that pgwin32_waitforsinglesocket is called from
pgwin32_send(), which will always have made the attempt to send data
first.
> It's a pity, but locking problem occurs only on SMP box and
> requires several hours to reproduce. So we are in testing now.
Yikes, that's definitely not nice :-)
//Magnus