pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Further stabilize a postgres_fdw test case. 7+ messages / 1 participants [nested] [flat]
* pgsql: Further stabilize a postgres_fdw test case. @ 2025-12-29 18:01 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2025-12-29 18:01 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further stabilize a postgres_fdw test case. This patch causes one postgres_fdw test case to revert to the plan it used before aa86129e1, i.e., using a remote sort in preference to local sort. That decision is actually a coin-flip because cost_sort() will give the same answer on both sides, so that the plan choice comes down to little more than roundoff error. In consequence, the test output can change as a result of even minor changes in nearby costs, as we saw in aa86129e1 (compare also b690e5fac and 4b14e1871). b690e5fac's solution to stabilizing the adjacent test case was to disable sorting locally, and here we extend that to the currently- problematic case. Without this, the following patch would cause this plan choice to change back in this same way, for even less apparent reason. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Chao Li <li.evan.chao@gmail.com> Discussion: https://postgr.es/m/2551253.1766952956@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/cb77bc04422fbbd1be48dde9794bfc0d0e5d7ad5 Modified Files -------------- contrib/postgres_fdw/expected/postgres_fdw.out | 22 +++++++++++----------- contrib/postgres_fdw/sql/postgres_fdw.sql | 12 ++++++++++-- 2 files changed, 21 insertions(+), 13 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case. @ 2026-02-11 16:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further stabilize a postgres_fdw test case. The buildfarm occasionally shows a variant row order in the output of this UPDATE ... RETURNING, implying that the preceding INSERT dropped one of the rows into some free space within the table rather than appending them all at the end. It's not entirely clear why that happens some times and not other times, but we have established that it's affected by concurrent activity in other databases of the cluster. In any case, the behavior is not wrong; the test is at fault for presuming that a seqscan will give deterministic row ordering. Add an ORDER BY atop the update to stop the buildfarm noise. The buildfarm seems to have shown this only in v18 and master branches, but just in case the cause is older, back-patch to all supported branches. Discussion: https://postgr.es/m/3866274.1770743162@sss.pgh.pa.us Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a3fd53babb8e8bde688739ec367a6d170495cfb4 Modified Files -------------- contrib/postgres_fdw/expected/postgres_fdw.out | 35 +++++++++++++++++--------- contrib/postgres_fdw/sql/postgres_fdw.sql | 11 ++++++-- 2 files changed, 32 insertions(+), 14 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case. @ 2026-02-11 16:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further stabilize a postgres_fdw test case. The buildfarm occasionally shows a variant row order in the output of this UPDATE ... RETURNING, implying that the preceding INSERT dropped one of the rows into some free space within the table rather than appending them all at the end. It's not entirely clear why that happens some times and not other times, but we have established that it's affected by concurrent activity in other databases of the cluster. In any case, the behavior is not wrong; the test is at fault for presuming that a seqscan will give deterministic row ordering. Add an ORDER BY atop the update to stop the buildfarm noise. The buildfarm seems to have shown this only in v18 and master branches, but just in case the cause is older, back-patch to all supported branches. Discussion: https://postgr.es/m/3866274.1770743162@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/946b653b7ab9f5c41f153cac7f05fe94772d8319 Modified Files -------------- contrib/postgres_fdw/expected/postgres_fdw.out | 35 +++++++++++++++++--------- contrib/postgres_fdw/sql/postgres_fdw.sql | 11 ++++++-- 2 files changed, 32 insertions(+), 14 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case. @ 2026-02-11 16:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further stabilize a postgres_fdw test case. The buildfarm occasionally shows a variant row order in the output of this UPDATE ... RETURNING, implying that the preceding INSERT dropped one of the rows into some free space within the table rather than appending them all at the end. It's not entirely clear why that happens some times and not other times, but we have established that it's affected by concurrent activity in other databases of the cluster. In any case, the behavior is not wrong; the test is at fault for presuming that a seqscan will give deterministic row ordering. Add an ORDER BY atop the update to stop the buildfarm noise. The buildfarm seems to have shown this only in v18 and master branches, but just in case the cause is older, back-patch to all supported branches. Discussion: https://postgr.es/m/3866274.1770743162@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/048a9f113d20310b19ee5ebfd513f5f87fcf516b Modified Files -------------- contrib/postgres_fdw/expected/postgres_fdw.out | 35 +++++++++++++++++--------- contrib/postgres_fdw/sql/postgres_fdw.sql | 11 ++++++-- 2 files changed, 32 insertions(+), 14 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case. @ 2026-02-11 16:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further stabilize a postgres_fdw test case. The buildfarm occasionally shows a variant row order in the output of this UPDATE ... RETURNING, implying that the preceding INSERT dropped one of the rows into some free space within the table rather than appending them all at the end. It's not entirely clear why that happens some times and not other times, but we have established that it's affected by concurrent activity in other databases of the cluster. In any case, the behavior is not wrong; the test is at fault for presuming that a seqscan will give deterministic row ordering. Add an ORDER BY atop the update to stop the buildfarm noise. The buildfarm seems to have shown this only in v18 and master branches, but just in case the cause is older, back-patch to all supported branches. Discussion: https://postgr.es/m/3866274.1770743162@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8277336992b8b0d8cb3ac2539f1ce08983db750e Modified Files -------------- contrib/postgres_fdw/expected/postgres_fdw.out | 35 +++++++++++++++++--------- contrib/postgres_fdw/sql/postgres_fdw.sql | 11 ++++++-- 2 files changed, 32 insertions(+), 14 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case. @ 2026-02-11 16:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further stabilize a postgres_fdw test case. The buildfarm occasionally shows a variant row order in the output of this UPDATE ... RETURNING, implying that the preceding INSERT dropped one of the rows into some free space within the table rather than appending them all at the end. It's not entirely clear why that happens some times and not other times, but we have established that it's affected by concurrent activity in other databases of the cluster. In any case, the behavior is not wrong; the test is at fault for presuming that a seqscan will give deterministic row ordering. Add an ORDER BY atop the update to stop the buildfarm noise. The buildfarm seems to have shown this only in v18 and master branches, but just in case the cause is older, back-patch to all supported branches. Discussion: https://postgr.es/m/3866274.1770743162@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/c10535fbea022113e470726b929e47833bcb1626 Modified Files -------------- contrib/postgres_fdw/expected/postgres_fdw.out | 35 +++++++++++++++++--------- contrib/postgres_fdw/sql/postgres_fdw.sql | 11 ++++++-- 2 files changed, 32 insertions(+), 14 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case. @ 2026-02-11 16:03 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Further stabilize a postgres_fdw test case. The buildfarm occasionally shows a variant row order in the output of this UPDATE ... RETURNING, implying that the preceding INSERT dropped one of the rows into some free space within the table rather than appending them all at the end. It's not entirely clear why that happens some times and not other times, but we have established that it's affected by concurrent activity in other databases of the cluster. In any case, the behavior is not wrong; the test is at fault for presuming that a seqscan will give deterministic row ordering. Add an ORDER BY atop the update to stop the buildfarm noise. The buildfarm seems to have shown this only in v18 and master branches, but just in case the cause is older, back-patch to all supported branches. Discussion: https://postgr.es/m/3866274.1770743162@sss.pgh.pa.us Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ec9f0cbe018a8c99aefcc19b688e8929fad4433c Modified Files -------------- contrib/postgres_fdw/expected/postgres_fdw.out | 35 +++++++++++++++++--------- contrib/postgres_fdw/sql/postgres_fdw.sql | 11 ++++++-- 2 files changed, 32 insertions(+), 14 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-02-11 16:03 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-12-29 18:01 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <tgl@sss.pgh.pa.us> 2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <tgl@sss.pgh.pa.us> 2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <tgl@sss.pgh.pa.us> 2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <tgl@sss.pgh.pa.us> 2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <tgl@sss.pgh.pa.us> 2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <tgl@sss.pgh.pa.us> 2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox