| From: | Fujii Masao <fujii(at)postgresql(dot)org> |
|---|---|
| To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
| Subject: | pgsql: Stabilize recovery conflict count checks in 031_recovery_conflic |
| Date: | 2026-10-05 04:05:55 |
| Message-ID: | E1xDZxb-00000000MD7-3fa5@gemulon.postgresql.org |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers |
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 <exclusion(at)gmail(dot)com>
Author: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Reviewed-by: Alexander Lakhin <exclusion(at)gmail(dot)com>
Reviewed-by: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Reviewed-by: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Discussion: https://postgr.es/m/421c0aee-84c8-4c07-b4b9-263095479755%40gmail.com
Backpatch-through: 17
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/92ee148b64ddc1685b5d0e74d5a083c0b22a6db7
Modified Files
--------------
src/test/recovery/t/031_recovery_conflict.pl | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-10-05 05:50:56 | pgsql: Don't take the address of flexible array members |
| Previous Message | Fujii Masao | 2026-10-05 04:05:41 | pgsql: Disable autovacuum in 031_recovery_conflict.pl |