Re: Escaping from blocked send() reprised. - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Escaping from blocked send() reprised.
Date
Msg-id 54061085.3050900@vmware.com
Whole thread Raw
In response to Re: Escaping from blocked send() reprised.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Escaping from blocked send() reprised.
Re: Escaping from blocked send() reprised.
Re: Escaping from blocked send() reprised.
List pgsql-hackers
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?

> - 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.

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.

- Heikki




pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Escaping from blocked send() reprised.
Next
From: Kevin Grittner
Date:
Subject: Re: PL/pgSQL 2