public inbox for [email protected]
help / color / mirror / Atom feedpgsql: Further stabilize a postgres_fdw test case.
6+ messages / 1 participants
[nested] [flat]
* pgsql: Further stabilize a postgres_fdw test case.
@ 2026-02-11 16:03 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw)
To: [email protected]
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/[email protected]
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] 6+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case.
@ 2026-02-11 16:03 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw)
To: [email protected]
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/[email protected]
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] 6+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case.
@ 2026-02-11 16:03 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw)
To: [email protected]
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/[email protected]
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] 6+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case.
@ 2026-02-11 16:03 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw)
To: [email protected]
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/[email protected]
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] 6+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case.
@ 2026-02-11 16:03 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw)
To: [email protected]
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/[email protected]
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] 6+ messages in thread
* pgsql: Further stabilize a postgres_fdw test case.
@ 2026-02-11 16:03 Tom Lane <[email protected]>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2026-02-11 16:03 UTC (permalink / raw)
To: [email protected]
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/[email protected]
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] 6+ messages in thread
end of thread, other threads:[~2026-02-11 16:03 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <[email protected]>
2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <[email protected]>
2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <[email protected]>
2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <[email protected]>
2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <[email protected]>
2026-02-11 16:03 pgsql: Further stabilize a postgres_fdw test case. Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox