Fix another bug in replication mode and snapshot isolation mode.
authorTatsuo Ishii <ishii@postgresql.org>
Sun, 11 Aug 2024 06:36:37 +0000 (15:36 +0900)
committerTatsuo Ishii <ishii@postgresql.org>
Sun, 11 Aug 2024 06:36:37 +0000 (15:36 +0900)
This is a follow up commit for 181d300de6337fe9a10b60ddbd782aa886b563e9.

If previous query produces parameter status message, subsequent
parse() needs to read and process it because it wants to read Ready
for query message which is supposed to follow the parameter status
message.  However when ParameterStatus() gets called, the query in
progress flag was set and it was possible that only one of parameter
status message from backend was processed if the query processed in
this parse() call is load balanced. It is likely that the parameter
status message comes from all live backend because they are generated
by SET command, and SET command are sent to all live backend in
replication mode and snapshot isolation mode. So unset the query in
progress flag before calling ParameterStatus().

Here is the test case written in pgproto data format.

'P' "" "SET application_name TO foo"
'B' "" "" 0 0 0
'E' "" 0
'P' "" "SELECT 1"
'B' "" "" 0 0 0
'E' "" 0
'P' "" "SET application_name TO bar"
'B' "" "" 0 0 0
'E' "" 0
'S'
'Y'
'X'

Backpatch-through: v4.1.

src/protocol/pool_proto_modules.c

index e62a3e0bf6494bdce0a8a48205a211ee880239df..71bad97d26acc504be0fe0e30e1e8708ec9fa77f 100644 (file)
@@ -1469,6 +1469,12 @@ Parse(POOL_CONNECTION * frontend, POOL_CONNECTION_POOL * backend,
                {
                        int                     i;
 
+                       /*
+                        * Temporarily unset query in progress so that all live backend
+                        * are processed.
+                        */
+                       pool_unset_query_in_progress();
+
                        /* synchronize transaction state */
                        for (i = 0; i < NUM_BACKENDS; i++)
                        {