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
signature.asc
Description: PGP signature
