|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Subject:||Re: Escaping from blocked send() reprised.|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Sorry, It tha patch contains a silly bug. Please find the
> 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
> 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.
|Next Message||Pavel Stehule||2014-09-05 08:40:32||Re: proposal: plpgsql - Assert statement|
|Previous Message||Marko Tiikkaja||2014-09-05 08:33:16||Re: proposal: plpgsql - Assert statement|