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:59:02 +0000 (15:59 +0900)
commiteeea97351602ebfb708145f6d49c07aad0102f0a
treec2b4d7aca8c79e850008ccb3c06a85f469d981f0
parent2376ab70fdf0a32e5891477b3990c1eb17d66f5a
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