pgsql: Process 'die' interrupts while reading/writing from the client s
Process 'die' interrupts while reading/writing from the client socket.
Up to now it was impossible to terminate a backend that was trying to
send/recv data to/from the client when the socket's buffer was already
full/empty. While the send/recv calls itself might have gotten
interrupted by signals on some platforms, we just immediately retried.
That could lead to situations where a backend couldn't be terminated ,
after a client died without the connection being closed, because it
was blocked in send/recv.
The problem was far more likely to be hit when sending data than when
reading. That's because while reading a command from the client, and
during authentication, we processed interrupts immediately . That
primarily left COPY FROM STDIN as being problematic for recv.
Change things so that that we process 'die' events immediately when
the appropriate signal arrives. We can't sensibly react to query
cancels at that point, because we might loose sync with the client as
we could be in the middle of writing a message.
We don't interrupt writes if the write buffer isn't full, as indicated
by write() returning EWOULDBLOCK, as that would lead to fewer error
messages reaching clients.
Per discussion with Kyotaro HORIGUCHI and Heikki Linnakangas
Discussion: 20140927191243.GD5423@alap3.anarazel.de
Branch
------
master
Details
-------
http://git.postgresql.org/pg/commitdiff/4fe384bd858671d40d311ca68cc9b80f4c683a3e
Modified Files
--------------
src/backend/libpq/be-secure-openssl.c | 24 ++++++++++----
src/backend/libpq/be-secure.c | 58 +++++++++++++++++++++------------
src/backend/tcop/postgres.c | 50 ++++++++++++++++++++++++++--
src/include/tcop/tcopprot.h | 3 +-
4 files changed, 105 insertions(+), 30 deletions(-)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
On 02/03/2015 11:51 PM, Andres Freund wrote:
+ * This is called just after low-level writes. That might be after the read + * finished successfully, or it was interrupted via interrupt. 'blocked' tells + * us whether the
Looks like you forgot to complete that sentence before pushing...
Also, nightjar is unhappy with this:
TRAP: FailedAssertion("!(InterruptHoldoffCount == 0 && CritSectionCount
== 0)", File:
"/pgbuild/root/HEAD/pgsql.build/../pgsql/src/backend/tcop/postgres.c",
Line: 574)
I think that assertion in ProcessClientWriteInterrupt() should be simply
removed. ProcessClientWriteInterrupt() copes just fine, i.e. does
nothing, if we're in a critical section or interrupts are held.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-02-04 00:47:03 +0200, Heikki Linnakangas wrote:
On 02/03/2015 11:51 PM, Andres Freund wrote:
+ * This is called just after low-level writes. That might be after the read + * finished successfully, or it was interrupted via interrupt. 'blocked' tells + * us whether theLooks like you forgot to complete that sentence before pushing...
Also, nightjar is unhappy with this:
TRAP: FailedAssertion("!(InterruptHoldoffCount == 0 && CritSectionCount ==
0)", File:
"/pgbuild/root/HEAD/pgsql.build/../pgsql/src/backend/tcop/postgres.c", Line:
574)I think that assertion in ProcessClientWriteInterrupt() should be simply
removed. ProcessClientWriteInterrupt() copes just fine, i.e. does nothing,
if we're in a critical section or interrupts are held.
Yea, it really was just a brainfart on my endq. It's perfectly normal to be called
that way during error handling...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers