Subject: Re: Regression failures after changing PostgreSQL blocksize

From: Álvaro Herrera <[email-masked]>
Date: Fri, 20 Feb 2026 22:42:46 +0100

On 2026-Feb-20, Alexandre Felipe wrote:

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

I doubt that will work.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"Entristecido, Wutra                     (canción de Las Barreras)
echa a Freyr a rodar
y a nosotros al mar"

---

From: Alexandre Felipe <[email-masked]>
Date: Sun, 22 Feb 2026 00:47:39 +0000

Hi Álvaro,

I think we can make it work

I just noticed that pg_regress provisioned `get_alternative_expectfile` for
that, and I see examples like `char{,_1,_2}.out`, but that is horrible for
maintenance (I personally think that we could have the input and expected
output in one single file).

I added a patch that would support selective matching. Check the README.md,
it contains some human readable instructions that I also used to test the
implementation. `make self-test` extracts examples from README.md and
runs pg_regress on them, i.e. test the implementation on the documentation.

https://asciinema.org/a/lFzGnv73mmOqyLWw

By default it ignores comments and spaces, and in the expected file you can
enable/disable other things, e.g. ignoring numbers in specific lines would
probably help with the 32kB failures.

Regards,
Alexandre

---

From: "David G. Johnston" <[email-masked]>
Date: Sat, 21 Feb 2026 19:19:10 -0700

On Saturday, February 21, 2026, Alexandre Felipe <
[email-masked]> wrote:

>
>  (I personally think that we could have the input and expected output in
> one single file).
>

Even if we could why would that be an improvement - green-field, let alone
the motivation for refactoring.

> probably help with the 32kB failures.

What’s the minimum functionality you’d need to get block size variances to
be auto-accepted using existing expected outputs.  Most/all of what you’ve
decided to allow to be ignored has no variability based on setting values
or environment - and likely would be stuff we wouldn’t want to be optional
(i.e., you need to justify each option).  And there is no demonstration of
actually solving the problem at hand.

I’d also go for an approach like: if block size <> 8kb then re-process any
exception output diffs/files again using the looser constraints.
Otherwise, stop and report test failure (status quo).  I’d be against
applying these kinds of bypasses to stock configured PostgreSQL for which a
complete set of copy-and-pasted expected files need to exist.

David J.

---

From: Alexandre Felipe <[email-masked]>
Date: Sun, 22 Feb 2026 08:47:05 +0000

The problem I was trying to solve was the total lack of configurability.

> Most/all of what you’ve decided to allow to be ignored has no variability
based on setting values or environment - and likely would be stuff we
wouldn’t want to be optional.

Now that you can see why my approach wouldn't work, could you suggest an
improvement on that? maybe different directives?

We could go for regular expressions, but I tried to give something simpler
before, and get feedback.

Could you please modify my README.md pretending you have something that
works, then I see if I can make it work. We could read compile options if
you want, or extract postgres default parameters. Embed blocks of code to
generate the output and so on.

If those tests are impossible to fix in regress/sql, should they be
promoted to TAP?

Maybe the tests are easy to fix, e.g. INSERT INTO toasttest values
(repeat('1234567890',300)); expects toasting, instead of 300 it should use
something based on current_setting(...), or set the minimum toast length on
the table.

In my regression it was just 30 failures, bad but not so bad.

Thank you for your input David
Alexandre

On Sun, Feb 22, 2026 at 2:19 AM David G. Johnston <
[email-masked]> wrote:

> By default it ignores comments and spaces, and in the expected file you
>> can enable/disable other things, e.g. ignoring numbers in specific lines
>> would probably help with the 32kB failures.
>>
>

---

From: "David G. Johnston" <[email-masked]>
Date: Sun, 22 Feb 2026 07:52:12 -0700

The convention here is to inline post replies while trimming quoted content
to only that which is being replied.

> The problem I was trying to solve was the total lack of configurability.

What do you think needs configuring and why?

>
> > Most/all of what you’ve decided to allow to be ignored has no
> variability based on setting values or environment - and likely would be
> stuff we wouldn’t want to be optional.
>

 I haven’t given it much thought and am just fine with the status quo.  But
I gave a couple of quick thoughts you may do with as you please.

> If those tests are impossible to fix in regress/sql, should they be

This approach, figuring out a way to run a set of tests under a specific
non-default configuration, seems more likely to be taken in.  But it seems
to me the odds are going to be low that anyone contributes new tests to the
file over the course of regular development.

> In my regression it was just 30 failures, bad but not so bad.

Then patch in the more robust query format that retains the intent of the
test.  Any other solution is going to quickly hit up against human
attention limitations.

David J.

---

From: Yasir <[email-masked]>
Date: Mon, 23 Feb 2026 02:30:27 +0500

> > What about pattern matching? being able to write regular expressions on

Might be relevant for the Perl tests, I haven't looked into that part yet.