Re: blkreftable.c needs more sanity checks

On Tue, Jul 14, 2026 at 3:27 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> + 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?

I can if you want, but I think if this happens IRL, you've probably
run pg_walsummary on something that was never intended as a WAL
summary file in the first place, and knowing what random nibble you
interpreted as a chunk size probably isn't going to help anything.

More broadly: To me, this is kind of the epitome of an AI-generated
bug report. It is definitely wrong. It should definitely be fixed. But
if AI hadn't found it, and we'd just waited for someone to discover it
by running into it, I'd guess that it would have taken decades for
that to happen, or maybe it would never have happened. So in some
sense we might be better off not knowing, because fixing this kind of
theoretical bug is taking up a lot of resources right now that we
could be spending on problems that matter more. Fixing this kind of
stuff seems essential at this point if only to prevent the same issues
from being re-reported over and over again and consuming even more
resources, and even if that were no issue, I'm too conscientious to
want to ignore stuff like this once I know about it. At the same time,
the benefit to PostgreSQL users is de minimis.

--
Robert Haas
EDB: http://www.enterprisedb.com