public inbox for [email protected]
help / color / mirror / Atom feedInstability in test/regress/sql/portals.sql
2+ messages / 2 participants
[nested] [flat]
* Instability in test/regress/sql/portals.sql
@ 2026-03-11 14:11 Matthias van de Meent <[email protected]>
2026-03-25 02:36 ` Re: Instability in test/regress/sql/portals.sql Michael Paquier <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Matthias van de Meent @ 2026-03-11 14:11 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
Hi,
Internally at Databricks we've seen rare regression failures in the
portals.sql test, where the regression diff looks something like the
one attached in data_attachments_ed2b37649a9393b5.diffs.
It seems like this was caused by synchronized seqscans, which caused
the foo25ns cursor to start its seqscan not at the start of the table,
but instead with an offset into the table. This changed the output,
because that relied on the seqscan starting at the first page of the
table.
To stabilize this test, let's add SET synchronize_seqscans = off, as attached.
Kind regards,
Matthias van de Meent
Databricks (https://www.databricks.com)
Attachments:
[application/octet-stream] data_attachments_ed2b37649a9393b5.diffs (2.9K, 2-data_attachments_ed2b37649a9393b5.diffs)
download
[application/octet-stream] v1-0001-Stabilize-syncscan-issue-in-pg_regress-portals.ou.patch (1.4K, 3-v1-0001-Stabilize-syncscan-issue-in-pg_regress-portals.ou.patch)
download | inline diff:
From 39e7a810c13f64660fc23a027a4ec314a343f36d Mon Sep 17 00:00:00 2001
From: Matthias van de Meent <[email protected]>
Date: Wed, 11 Mar 2026 13:45:28 +0100
Subject: [PATCH v1] Stabilize syncscan issue in pg_regress' portals.out
---
src/test/regress/expected/portals.out | 2 ++
src/test/regress/sql/portals.sql | 3 +++
2 files changed, 5 insertions(+)
diff --git a/src/test/regress/expected/portals.out b/src/test/regress/expected/portals.out
index 06726ed4ab7..38506abe0df 100644
--- a/src/test/regress/expected/portals.out
+++ b/src/test/regress/expected/portals.out
@@ -1,6 +1,7 @@
--
-- Cursor regression tests
--
+SET synchronize_seqscans = off;
BEGIN;
DECLARE foo1 SCROLL CURSOR FOR SELECT * FROM tenk1 ORDER BY unique2;
DECLARE foo2 SCROLL CURSOR FOR SELECT * FROM tenk2;
@@ -1561,3 +1562,4 @@ fetch all in held_portal;
(1 row)
reset default_toast_compression;
+reset synchronize_seqscans;
diff --git a/src/test/regress/sql/portals.sql b/src/test/regress/sql/portals.sql
index fc4cccb96c0..995fef597bd 100644
--- a/src/test/regress/sql/portals.sql
+++ b/src/test/regress/sql/portals.sql
@@ -2,6 +2,8 @@
-- Cursor regression tests
--
+SET synchronize_seqscans = off;
+
BEGIN;
DECLARE foo1 SCROLL CURSOR FOR SELECT * FROM tenk1 ORDER BY unique2;
@@ -605,3 +607,4 @@ drop table toasted_data;
fetch all in held_portal;
reset default_toast_compression;
+reset synchronize_seqscans;
--
2.50.1 (Apple Git-155)
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Instability in test/regress/sql/portals.sql
2026-03-11 14:11 Instability in test/regress/sql/portals.sql Matthias van de Meent <[email protected]>
@ 2026-03-25 02:36 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Michael Paquier @ 2026-03-25 02:36 UTC (permalink / raw)
To: Matthias van de Meent <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Wed, Mar 11, 2026 at 03:11:36PM +0100, Matthias van de Meent wrote:
> Internally at Databricks we've seen rare regression failures in the
> portals.sql test, where the regression diff looks something like the
> one attached in data_attachments_ed2b37649a9393b5.diffs.
>
> It seems like this was caused by synchronized seqscans, which caused
> the foo25ns cursor to start its seqscan not at the start of the table,
> but instead with an offset into the table. This changed the output,
> because that relied on the seqscan starting at the first page of the
> table.
>
> To stabilize this test, let's add SET synchronize_seqscans = off, as attached.
One could be reminded about cbf4177f2ca0, as well, when using a low
number of shared buffers. My question would be why only this test?
And isn't there some benefit in running this part of the test suite
with the parameter enabled?
Sync seqscans disabled is a pre-8.3 behavior, and I'd be tempted to
suggest that we drop the GUC while making the recovery test 027 use
more shared buffers but we tend to be really conservative with these
tests, so I doubt that this is going to happen. ;)
Or you could just force that on your end with a custom .conf file? We
have plenty of configuration that can influence the outcome of the
tests, and it is not obvious why this particular case is worth caring
for when it comes to the upstream core tests.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-03-25 02:36 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-03-11 14:11 Instability in test/regress/sql/portals.sql Matthias van de Meent <[email protected]>
2026-03-25 02:36 ` Michael Paquier <[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