Re: Regression failures after changing PostgreSQL blocksize

What about pattern matching? being able to write regular expressions on the
expected outputs?

On Thu, Feb 12, 2026 at 8:08 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:

> On 2026-Feb-13, Yasir wrote:
>
> > can we add alternative test output files for the changes caused by
> > different block sizes? E.g: the attached poc patch. Whether such an
> > approach would be acceptable?
>
> Absolutely not. For starters, how did you verify that these new files
> are correct? Second, I imagine this patch is just for this one file,
> but that there numerous other files that would have to be patched,
> right? If so, how many, and how extensive are the changes?
>
> If you wanted to propose some surgical interventions to the affected
> files that made the tests pass for other page sizes, then perhaps that
> could be entertained. Looking at the files you sent, I see that from
> the original to _2.out there are two plan changes (hash aggregates
> become group aggregates); then from _2.out to _1.out a single query
> changes from indexscan to bitmap scan; and lastly, from the original to
> _3.out there are some seqscans that become index scans. So if you were
> to propose a patch that adds a SET call to disable some plan type just
> before one query, and RESET it immediately after that query; and with
> such a change the test runs unchanged across all block sizes, then maybe
> that would be something we could consider. (However, getting a
> committer to review such changes might be a hard sell also -- no
> promises!)
>
> Also, if you find that you need too many changes of this kind in order
> to make this work, then that's probably not going to fly either.
>
> > Which other compile time options are expected to cause test failures?
>
> You're welcome to experiment and let us know what you find.
>
> --
> Álvaro Herrera Breisgau, Deutschland —
> https://www.EnterpriseDB.com/
>
>
>