Call pqPipelineFlush from PQsendFlushRequest

When PQsendFlushRequest() was added by commit 69cf1d5429d4, we argued
against adding a PQflush() call in it[1].  This is still the right
decision: if the user wants a flush to occur, they can just call that.
However, we failed to realize that the message bytes could still be
given to the kernel for transmitting when this can be made without
blocking.  That's what pqPipelineFlush() does, and it is done for every
single other message type sent by libpq, so do that.

(When the socket is in blocking mode this may indeed block, but that's
what all the other libpq message-sending routines do, too.)

[1] https://www.postgresql.org/message-id/202106252352.5ca4byasfun5%40alvherre.pgsql

Author: Jelte Fennema-Nio <[email protected]>
Discussion: https://postgr.es/m/CAGECzQTxZRevRWkKodE-SnJk1Yfm4eKT+8E4Cyq3MJ9YKTnNew@mail.gmail.com

diff --git a/src/interfaces/libpq/fe-exec.c b/src/interfaces/libpq/fe-exec.c
index 1800d7365be4f09b7496e2eaac703742de26dceb..08326895ee4c0033c6ce43ea7f1b6568ecad5a87 100644 (file)
--- a/src/interfaces/libpq/fe-exec.c
+++ b/src/interfaces/libpq/fe-exec.c
@@ -3252,6 +3252,14 @@ PQsendFlushRequest(PGconn *conn)
        return 0;
    }
 
+   /*
+    * Give the data a push (in pipeline mode, only if we're past the size
+    * threshold).  In nonblock mode, don't complain if we're unable to send
+    * it all; PQgetResult() will do any additional flushing needed.
+    */
+   if (pqPipelineFlush(conn) < 0)
+       return 0;
+
    return 1;
 }