Re: blkreftable.c needs more sanity checks

> On 14 Jul 2026, at 00:17, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> The reason why the impact of this is pretty limited is that WAL
> summary files are only supposed to exist in $PGDATA, and if an
> adversary has write access to $PGDATA, they will probably do something
> much worse than introduce a maliciously-constructed WAL summary file.

Agreed.

> As a practical matter, the main benefit of this fix is to contain the
> damage in case of an *accidentally* corrupted WAL summary file. Of
> course, such a file won't be usable for its intended purpose with or
> without this fix, but with this fix, the outcome is more likely to be
> an error and less likely to be a crash, either of the server or of
> pg_walsummary.

Makes sense, not that the error will be particularly actionable but it will
give more clues than a crash. Looking at the callsites they all call
DestroyBlockRefTableReader on BlockRefTableReaderNextRelation returning false
so leaving chunk_size allocated on error return does not leak.

+ reader->error_callback(reader->error_callback_arg,
+ "file \"%s\" has oversized chunk",
+ reader->error_filename);

Any reason not to print the offending chunk size to aid debugging of this type
of should-never-happen scenario?

+1 on the patch and backpatch plan.

--
Daniel Gustafsson