Fix statement_level_load_balance with BEGIN etc.
authorTatsuo Ishii <ishii@sraoss.co.jp>
Sat, 10 Feb 2024 02:50:28 +0000 (11:50 +0900)
committerTatsuo Ishii <ishii@sraoss.co.jp>
Sat, 10 Feb 2024 02:50:28 +0000 (11:50 +0900)
commit3f3c165698d8ded0a96d24ee93b32bc6973dab6d
tree6f8b22a1a6129118e0c4baf7bba7a5dcd97e748c
parent6b307671b244c65f34f11ed628a82201c15e28b9
Fix statement_level_load_balance with BEGIN etc.

When statement_level_load_balance is enabled,
BEGIN/END/COMMIT/ABORT/SET/SAVEPOINT/RELEASE SAVEPOINT/DEALLOCATE
ALL/DISCARD were sent to primary node and all standby nodes even if
load_balance_mode is off. This is not only plain wrong but caused slow
down if one of the standby nodes are in remote network. Fix this in
that pgpool sends such queries to primary node only when
load_balance_mode is off.

Note that if load_balance_mode is on and statement_level_load_balance
is on, such queries are sent to all nodes as before. This is
necessary. For example, suppose there are 2 PostgreSQL nodes 0 and
1. An explicit transaction starts followed by two read only
SELECTs. The first SELECT is sent to node 0 because the node 0 is
chosen as the load balance node. The second SELECT is sent to node 1
because the node 1 is chosen as the load balance node. If pgpool has
not sent BEGIN to both node 0 and 1 when the transaction started, the
first or the second SELECT will be executed outside the transaction,
which is not an expected behavior. However this may bring slow down
mentioned above. I guess this has been less known to users and I
decided to add some notes to the statement_level_load_balance doc.

Reported: [pgpool-general: 8998] https://www.pgpool.net/pipermail/pgpool-general/2024-January/009059.html
Discussion: [pgpool-hackers: 4422] https://www.pgpool.net/pipermail/pgpool-hackers/2024-February/004423.html
Backpatch-through: v4.1
doc.ja/src/sgml/loadbalance.sgml
doc/src/sgml/loadbalance.sgml
src/context/pool_query_context.c