Hello, attached is the new-and-far-simple version of this
patch. It no longer depends on win32 nonblocking patch since the
socket is in blocking mode again.
> On 08/28/2014 03:47 PM, Kyotaro HORIGUCHI wrote:
> > - Preventing protocol violation.
> >
> > To prevent protocol violation, secure_write sets
> > ClientConnectionLost when SIGTERM detected, then
> > internal_flush() and ProcessInterrupts() follow the
> > instruction.
>
> Oh, hang on. Now that I look at pqcomm.c more closely, it already has
> a mechanism to avoid writing a message in the middle of another
> message. See pq_putmessage and PqCommBusy. Can we rely on that?
Hmm, it gracefully returns up to ExecProcNode() and PqCommBusy is
turned off on the way at pq_putmessage() under current
implement. So PqCommBusy is already false before it runs into
ProcessInterrupts().
Allowing ImmediateInterruptOK on signalled during send(), setting
whereToSendOutput to DestNone if PqCommBusy is true will do. We
can also distinguish read and write by looking
DoingCommandRead. The ImmediateInterruptOK section can be defined
enclosing by prepare_for_client_read/client_read_end.
> > - Single pg_terminate_backend surely kills the backend.
> >
> > secure_raw_write() uses non-blocking socket and a loop of
> > select() with timeout to surely detects received
> > signal(SIGTERM).
>
> I was going to suggest using WaitLatchOrSocket instead of sleeping in
> 1 second increment, but I see that WaitLatchOrSocket() doesn't
> currently support waiting for a socket to become writeable, without
> also waiting for it to become readable. I wonder how difficult it
> would be to lift that restriction.
It seems quite difficult hearing the following discussion.
> I also wonder if it would be simpler to keep the socket in blocking
> mode after all, and just close() in the signal handler if PqCommBusy
> == true. If the signal arrives while sleeping in send(), the effect
> would be the same as with your patch. If the signal arrives while
> sending, but not sleeping, you would not get the chance to send the
> already-buffered data to the client. But maybe that's OK, whether or
> not you're blocked is not very deterministic anyway.
Hmm. We're back round to the my first patch, with immediately
close the socket, and became irrelevant to win32 layer
patch. Anyway, it sounds reasonable.
Attached patch is a quick hack patch, but it seems working as
expected at a glance.
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center