Fix prefer_lower_delay_standby bug.
authorTatsuo Ishii <ishii@sraoss.co.jp>
Sun, 30 Apr 2023 06:41:02 +0000 (15:41 +0900)
committerTatsuo Ishii <ishii@sraoss.co.jp>
Sun, 30 Apr 2023 06:41:02 +0000 (15:41 +0900)
commitc7f9be67e28cee86064df807f2a98920e3c47c6e
tree60b6c0b5c53ffcac36a18818705aa9131e28ab18
parent9676ba9748c80bf5d53dc441b3b17e428901f022
Fix prefer_lower_delay_standby bug.

When client connects to pgpool, one of standbys are chosen as the load
balancing node.  If standby delay exceeds delay_threshold while the
session continues, prefer_lower_delay_standby will choose the least
delay standby node as the new load balancing node and set the target
backend to the node. Unfortunately the decision was made *before* the
checking that SELECT query includes writing function etc., pgpool
happily sends SELECT which cannot be executed on standby.  To fix
this, prefer_lower_delay_standby treatment is moved after the writing
function etc. check.

033.prefer_lower_standby_delay regression test is modified to include
the case above. Also I have done some refactoring:

- Remove unnecessary while loop for each clustering mode because the
  test is only useful for streaming replication mode.

- Add checking wal_replay_pause is actually executed.

Bug reported by: https://www.pgpool.net/mantisbt/view.php?id=798
along with suggested fix.
src/context/pool_query_context.c
src/test/regression/tests/033.prefer_lower_standby_delay/test.sh