Stabilize recovery conflict count checks in 031_recovery_conflict.pl Buildfarm members olingo and adder reported failures in 031_recovery_conflict.pl where a recovery conflict was counted twice. olingo saw the snapshot conflict count reach 2 instead of 1, while adder saw the same for the buffer pin conflict count.
The startup process can signal a standby backend again while it is reporting a recovery-conflict FATAL error. Each processed conflict can increment the corresponding statistic. Thus, even when the expected conflict occurs, its counter can exceed 1. The existing poll for exactly 1 can then time out, and the exact check of the aggregate count can fail as well. Fix this by polling for a positive count for each conflict type and accepting an aggregate count of at least the expected number. Backpatch to v17, where this test was enabled. Reported-by: Alexander Lakhin <[email protected]> Author: Ayush Tiwari <[email protected]> Reviewed-by: Alexander Lakhin <[email protected]> Reviewed-by: Nazir Bilal Yavuz <[email protected]> Reviewed-by: Fujii Masao <[email protected]> Discussion: https://postgr.es/m/421c0aee-84c8-4c07-b4b9-263095479755%40gmail.com Backpatch-through: 17 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8ea5048263c6ef9bd91de8f0ba0857976f94008f Modified Files -------------- src/test/recovery/t/031_recovery_conflict.pl | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-)
