Regression failures after changing PostgreSQL blocksize

FYI

On Wed, Feb 11, 2026 at 11:19 PM Yasir <yasir.hussain.shah@gmail.com> wrote:

On Thu, Feb 12, 2026 at 7:19 AM Yasir <yasir.hussain.shah@gmail.com> wrote:

I recently configured PostgreSQL with a custom blocksize:

./configure --with-blocksize=32
make && make check
OR
make && make check-world

This produced so many regression failures. I'm wondering, are such failures typical/expected when altering the default block size?
I came across a related discussion, but it dates back more than a decade. It would be great to get current perspectives.

Yes, that is known. I suspect there won't be wide interest in custom
block sizes until/unless we can change them at run time (as is
occasionally proposed, since there are known benefits to using smaller
blocks for OLTP and larger blocks for OLAP), and if that ever happens
I guess those regression tests will probably still need to run with
the traditional size.

Hi,

since there are known benefits to using smaller
blocks for OLTP and larger blocks for OLAP), and if that ever happens
I guess those regression tests will probably still need to run with
the traditional size.

Yes,  In Greenplum and Apache Cloudberry, we've been using a default block size of 32KB for many years.

On Feb 12, 2026 at 05:05 +0800, Thomas Munro <thomas.munro@gmail.com>, wrote:

On Thu, Feb 12, 2026 at 7:19 AM Yasir <yasir.hussain.shah@gmail.com> wrote:

I recently configured PostgreSQL with a custom blocksize:

./configure --with-blocksize=32
make && make check
OR
make && make check-world

This produced so many regression failures. I'm wondering, are such failures typical/expected when altering the default block size?

Our experience shows that when changing the block size, most of the regression test differences are expected — they often reflect output variations (like buffer counts, cost estimates, or physical storage details) rather than functional bugs.

That said, it really needs to be examined case by case.
If the change causes a server crash, wrong query results, or any kind of data corruption, that’s definitely a red flag and worth investigating seriously.
So while many of the failures you saw are likely harmless, it's still good practice to verify the ones that look suspicious.

--
Zhang Mingli
HashData

Zhang Mingli <zmlpostgres@gmail.com> writes:

On Thu, Feb 12, 2026 at 7:19 AM Yasir <yasir.hussain.shah@gmail.com> wrote:

This produced so many regression failures. I'm wondering, are such failures typical/expected when altering the default block size?

Our experience shows that when changing the block size, most of the regression test differences are expected — they often reflect output variations (like buffer counts, cost estimates, or physical storage details) rather than functional bugs.
That said, it really needs to be examined case by case.

Indeed. There is relevant documentation here:

https://www.postgresql.org/docs/current/regress-evaluation.html

(Some of that looks a bit out of date, ie differences we don't really
expect to happen anymore. But plan changes and row-ordering changes
are definitely expected if you change any parameter that affects
planner cost estimates.)

regards, tom lane

Hi,

Thank you all for providing invaluable information. Based on the answers,
it's clear that regression failures with custom block sizes are expected
and not necessarily indicative of functional bugs.
However, it creates doubts, so, 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?

Which other compile time options are expected to cause test failures?

Regards,

Yasir Hussain Shah
Data Bene

On Thu, Feb 12, 2026 at 7:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Hi,

On 2026-02-13 00:18:39 +0500, Yasir wrote:

Thank you all for providing invaluable information. Based on the answers,
it's clear that regression failures with custom block sizes are expected
and not necessarily indicative of functional bugs.
However, it creates doubts, so, 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?

No. That'd require everyone modifying these tests to test with multiple block
sizes. That'd almost certainly be forgotten and the alternative files would
get out of date. And if not forgotten, it's extra work for pretty much no
gain.

Which other compile time options are expected to cause test failures?

I know of one: Using an extremely small --with-segsize-blocks (less than
something like 6 or 8 blocks) causes some test failures. There are some
pg_config_manual.h and a lot more other defines that, if changed, would also
cause "spurious" test failures.

Greetings,

Andres Freund

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/

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@kurilemu.de> wrote:

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"

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

On Fri, Feb 20, 2026 at 9:42 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:

On Saturday, February 21, 2026, Alexandre Felipe <
o.alexandre.felipe@gmail.com> 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.

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.

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.

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 <
david.g.johnston@gmail.com> wrote:

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

On Sunday, February 22, 2026, Alexandre Felipe <o.alexandre.felipe@gmail.com>
wrote:

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.

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

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
promoted to TAP?

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.

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.

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.

On Fri, Feb 13, 2026 at 1:08 AM Álvaro Herrera <alvherre@kurilemu.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?

I'm not sure whether this POC file (or other files) is accurate. Clearly,
if we proceed with this approach to address the regression issues, it will
need to be verified by expert reviewers.

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?

Correct. I have reviewed the entire set, approximately 30 files, and all of
them require adjustments to their outputs. The necessary changes are
largely similar to the modifications shown in the alternative output file
referenced above.

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!)

Thank you, you've hit the nail on the head. By comparing the alternative
outputs to the original, you've clearly understood what I was aiming for.
As for the SET/RESET solution, I hadn't considered that approach myself;
it's an interesting angle. As long as it doesn't compromise the purpose of
the regression, it looks like a solid approach.

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.

There are around 30 files in total that will need alternative outputs.

Which other compile time options are expected to cause test failures?

You're welcome to experiment and let us know what you find.

I'll experiment, assuming I get a chance in this lifetime! :)

On Sat, Feb 21, 2026 at 2:42 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:

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.

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

On 2026-Feb-23, Yasir wrote:

I'll experiment, assuming I get a chance in this lifetime! :)

I suggest to stop using an LLM to write your responses.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Curiosity is the hope that something wondrous waits just out of sight,
for we are surrounded by a garden of miracles" (Namron)
(Marjorie Liu and Sana Takeda, Monstress: Inferno)

On 12.02.26 21:08, Álvaro Herrera 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.

AFAICT, the differences fall into three categories:

1) tests that intentionally test block size and related limits

2) printed plan changes

3) ordering changes (probably due to plan changes)

The first category might be worth fixing by parametrizing the tests on
the block size at run time. This would check that the various edge
cases also work correctly under different block sizes, which could be
valuable.

About the plan changes, I'm surprised that there are that many plan
changes. I wonder if it would help a bit to change some planner
settings like work_mem proportionally to the block size (either globally
or just for the tests).