agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Stabilize recovery conflict stats checks in 031_recovery_conflic 4+ messages / 1 participants [nested] [flat]
* pgsql: Stabilize recovery conflict stats checks in 031_recovery_conflic @ 2026-09-03 03:17 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: Fujii Masao @ 2026-09-03 03:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Stabilize recovery conflict stats checks in 031_recovery_conflict.pl The buildfarm member akepa reported a failure in the 031_recovery_conflict.pl test. The test checked pg_stat_database_conflicts immediately after detecting a recovery conflict in the standby log. However, the conflict counter is flushed by the canceled backend during backend exit, so WAL replay completion and the log message did not guarantee that the updated statistics are visible yet. So, previously, the test could see a conflict counter of 0 even though the conflict had already occurred, triggering the test failure. Fix this by polling for the expected conflict counter instead of reading it only once, handling the asynchronous pgstats update. Per buildfarm member akepa. Backpatch to v17, where this test is enabled and has the same race. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/CAHGQGwHmiLNRfvJDAR=PmxQgf7DbzPSO1M-1RoqO8oy=t2G5KA@mail.gmail.com Backpatch-through: 17 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/7d0a31fa22c8e830280e91e1a181d8be04e8632a Modified Files -------------- src/test/recovery/t/031_recovery_conflict.pl | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Stabilize recovery conflict stats checks in 031_recovery_conflic @ 2026-09-03 03:17 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: Fujii Masao @ 2026-09-03 03:17 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Stabilize recovery conflict stats checks in 031_recovery_conflict.pl The buildfarm member akepa reported a failure in the 031_recovery_conflict.pl test. The test checked pg_stat_database_conflicts immediately after detecting a recovery conflict in the standby log. However, the conflict counter is flushed by the canceled backend during backend exit, so WAL replay completion and the log message did not guarantee that the updated statistics are visible yet. So, previously, the test could see a conflict counter of 0 even though the conflict had already occurred, triggering the test failure. Fix this by polling for the expected conflict counter instead of reading it only once, handling the asynchronous pgstats update. Per buildfarm member akepa. Backpatch to v17, where this test is enabled and has the same race. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/CAHGQGwHmiLNRfvJDAR=PmxQgf7DbzPSO1M-1RoqO8oy=t2G5KA@mail.gmail.com Backpatch-through: 17 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9431cce4dc97fe3eaad73e6f98ac16d62755eb82 Modified Files -------------- src/test/recovery/t/031_recovery_conflict.pl | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Stabilize recovery conflict stats checks in 031_recovery_conflic @ 2026-09-03 03:18 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: Fujii Masao @ 2026-09-03 03:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Stabilize recovery conflict stats checks in 031_recovery_conflict.pl The buildfarm member akepa reported a failure in the 031_recovery_conflict.pl test. The test checked pg_stat_database_conflicts immediately after detecting a recovery conflict in the standby log. However, the conflict counter is flushed by the canceled backend during backend exit, so WAL replay completion and the log message did not guarantee that the updated statistics are visible yet. So, previously, the test could see a conflict counter of 0 even though the conflict had already occurred, triggering the test failure. Fix this by polling for the expected conflict counter instead of reading it only once, handling the asynchronous pgstats update. Per buildfarm member akepa. Backpatch to v17, where this test is enabled and has the same race. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/CAHGQGwHmiLNRfvJDAR=PmxQgf7DbzPSO1M-1RoqO8oy=t2G5KA@mail.gmail.com Backpatch-through: 17 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8254de34bc4226756755ee585c0e24dd995e12a2 Modified Files -------------- src/test/recovery/t/031_recovery_conflict.pl | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: Stabilize recovery conflict stats checks in 031_recovery_conflic @ 2026-09-03 03:18 Fujii Masao <fujii@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: Fujii Masao @ 2026-09-03 03:18 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Stabilize recovery conflict stats checks in 031_recovery_conflict.pl The buildfarm member akepa reported a failure in the 031_recovery_conflict.pl test. The test checked pg_stat_database_conflicts immediately after detecting a recovery conflict in the standby log. However, the conflict counter is flushed by the canceled backend during backend exit, so WAL replay completion and the log message did not guarantee that the updated statistics are visible yet. So, previously, the test could see a conflict counter of 0 even though the conflict had already occurred, triggering the test failure. Fix this by polling for the expected conflict counter instead of reading it only once, handling the asynchronous pgstats update. Per buildfarm member akepa. Backpatch to v17, where this test is enabled and has the same race. Author: Fujii Masao <masao.fujii@gmail.com> Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com> Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/CAHGQGwHmiLNRfvJDAR=PmxQgf7DbzPSO1M-1RoqO8oy=t2G5KA@mail.gmail.com Backpatch-through: 17 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a830fa886cee8b5c366787c50aadb1d5f17b2348 Modified Files -------------- src/test/recovery/t/031_recovery_conflict.pl | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-09-03 03:18 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-09-03 03:17 pgsql: Stabilize recovery conflict stats checks in 031_recovery_conflic Fujii Masao <fujii@postgresql.org> 2026-09-03 03:17 pgsql: Stabilize recovery conflict stats checks in 031_recovery_conflic Fujii Masao <fujii@postgresql.org> 2026-09-03 03:18 pgsql: Stabilize recovery conflict stats checks in 031_recovery_conflic Fujii Masao <fujii@postgresql.org> 2026-09-03 03:18 pgsql: Stabilize recovery conflict stats checks in 031_recovery_conflic Fujii Masao <fujii@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox