Skip to content

Commit 2a3f6e3

Browse files
committed
Fix potential deadlock with libpq non-blocking mode.
If libpq output buffer is full, pqSendSome() function tries to drain any incoming data. This avoids deadlock, if the server e.g. sends a lot of NOTICE messages, and blocks until we read them. However, pqSendSome() only did that in blocking mode. In non-blocking mode, the deadlock could still happen. To fix, take a two-pronged approach: 1. Change the documentation to instruct that when PQflush() returns 1, you should wait for both read- and write-ready, and call PQconsumeInput() if it becomes read-ready. That fixes the deadlock, but applications are not going to change overnight. 2. In pqSendSome(), drain the input buffer before returning 1. This alleviates the problem for applications that only wait for write-ready. In particular, a slow but steady stream of NOTICE messages during COPY FROM STDIN will no longer cause a deadlock. The risk remains that the server attempts to send a large burst of data and fills its output buffer, and at the same time the client also sends enough data to fill its output buffer. The application will deadlock if it goes to sleep, waiting for the socket to become write-ready, before the server's data arrives. In practice, NOTICE messages and such that the server might be sending are usually short, so it's highly unlikely that the server would fill its output buffer so quickly. Backpatch to all supported versions.
1 parent c063da1 commit 2a3f6e3

File tree

2 files changed

+25
-11
lines changed

2 files changed

+25
-11
lines changed

doc/src/sgml/libpq.sgml

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4503,7 +4503,14 @@ int PQflush(PGconn *conn);
45034503
<para>
45044504
After sending any command or data on a nonblocking connection, call
45054505
<function>PQflush</function>. If it returns 1, wait for the socket
4506-
to be write-ready and call it again; repeat until it returns 0. Once
4506+
to become read- or write-ready. If it becomes write-ready, call
4507+
<function>PQflush</function> again. If it becomes read-ready, call
4508+
<function>PQconsumeInput</function>, then call
4509+
<function>PQflush</function> again. Repeat until
4510+
<function>PQflush</function> returns 0. (It is necessary to check for
4511+
read-ready and drain the input with <function>PQconsumeInput</function>,
4512+
because the server can block trying to send us data, e.g. NOTICE
4513+
messages, and won't read our data until we read its.) Once
45074514
<function>PQflush</function> returns 0, wait for the socket to be
45084515
read-ready and then read the response as described above.
45094516
</para>

src/interfaces/libpq/fe-misc.c

Lines changed: 17 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -905,16 +905,6 @@ pqSendSome(PGconn *conn, int len)
905905
/*
906906
* We didn't send it all, wait till we can send more.
907907
*
908-
* If the connection is in non-blocking mode we don't wait, but
909-
* return 1 to indicate that data is still pending.
910-
*/
911-
if (pqIsnonblocking(conn))
912-
{
913-
result = 1;
914-
break;
915-
}
916-
917-
/*
918908
* There are scenarios in which we can't send data because the
919909
* communications channel is full, but we cannot expect the server
920910
* to clear the channel eventually because it's blocked trying to
@@ -925,12 +915,29 @@ pqSendSome(PGconn *conn, int len)
925915
* again. Furthermore, it is possible that such incoming data
926916
* might not arrive until after we've gone to sleep. Therefore,
927917
* we wait for either read ready or write ready.
918+
*
919+
* In non-blocking mode, we don't wait here directly, but return
920+
* 1 to indicate that data is still pending. The caller should
921+
* wait for both read and write ready conditions, and call
922+
* PQconsumeInput() on read ready, but just in case it doesn't, we
923+
* call pqReadData() ourselves before returning. That's not
924+
* enough if the data has not arrived yet, but it's the best we
925+
* can do, and works pretty well in practice. (The documentation
926+
* used to say that you only need to wait for write-ready, so
927+
* there are still plenty of applications like that out there.)
928928
*/
929929
if (pqReadData(conn) < 0)
930930
{
931931
result = -1; /* error message already set up */
932932
break;
933933
}
934+
935+
if (pqIsnonblocking(conn))
936+
{
937+
result = 1;
938+
break;
939+
}
940+
934941
if (pqWait(TRUE, TRUE, conn))
935942
{
936943
result = -1;

0 commit comments

Comments
 (0)