database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-30 21:42:05 +03:00
Code Activity

Adjust libpq to avoid deadlock when both client and server want to send

Browse Source 
data, and both have filled the transmission buffers.  One scenario where
this can happen was illustrated here:
http://archives.postgresql.org/pgsql-hackers/2003-04/msg00979.php
This commit is contained in:
Tom Lane
2003-10-19 21:36:41 +00:00
parent d5353acbc3
commit 9dfdbef345
2 changed files with 31 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
src/interfaces/libpq/fe-misc.c
View File

@ -23,7 +23,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/interfaces/libpq/fe-misc.c,v 1.102 2003/08/08 21:42:55 momjian Exp $
* $Header: /cvsroot/pgsql/src/interfaces/libpq/fe-misc.c,v 1.103 2003/10/19 21:36:41 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -828,7 +828,24 @@ pqSendSome(PGconn *conn, int len)
break;
}
if (pqWait(FALSE, TRUE, conn))
/*
* There are scenarios in which we can't send data because the
* communications channel is full, but we cannot expect the server
* to clear the channel eventually because it's blocked trying to
* send data to us. (This can happen when we are sending a large
* amount of COPY data, and the server has generated lots of
* NOTICE responses.) To avoid a deadlock situation, we must be
* prepared to accept and buffer incoming data before we try
* again. Furthermore, it is possible that such incoming data
* might not arrive until after we've gone to sleep. Therefore,
* we wait for either read ready or write ready.
*/
if (pqReadData(conn) < 0)
{
result = -1; /* error message already set up */
break;
}
if (pqWait(TRUE, TRUE, conn))
{
result = -1;
break;