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 09:19:15 +0000 (18:19 +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 1ad29650bc31f32f04bd789ca3ceb914a27c1559..1bebe8e7aac4f63634c166c7b7fba9679e18d84c 100644 (file)
@@ -1470,6 +1470,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++)
                        {