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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
