postgres.git / summary / log / commit / refs

commit    0e28091d5507bd63d5ad51e9795dd368aa4c7c4c
Author:   Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:     Wed Nov 08 15:44:08 2023 +0000
First released in: 17.0, 14.11, 15.6, 16.2

    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 <postgres@jeltef.nl>
    Discussion: https://postgr.es/m/CAGECzQTxZRevRWkKodE-SnJk1Yfm4eKT+8E4Cyq3MJ9YKTnNew@mail.gmail.com


 src/interfaces/libpq/fe-exec.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/interfaces/libpq/fe-exec.c b/src/interfaces/libpq/fe-exec.c
index 8989f7102d4..ce10a41eb41 100644
--- a/src/interfaces/libpq/fe-exec.c
+++ b/src/interfaces/libpq/fe-exec.c
@@ -3271,6 +3271,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;
 }
 


[parent: 7e18c0bd63ae]