public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Matthias van de Meent <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Instability in test/regress/sql/portals.sql
Date: Wed, 25 Mar 2026 11:36:37 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAEze2Wi0hg46bcvLQrjid6Kvbb+NSR1N5OKbDNfHy2J=JutJ=Q@mail.gmail.com>
References: <CAEze2Wi0hg46bcvLQrjid6Kvbb+NSR1N5OKbDNfHy2J=JutJ=Q@mail.gmail.com>
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
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Instability in test/regress/sql/portals.sql
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox