Re: blkreftable.c needs more sanity checks

> On 14 Jul 2026, at 13:21, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> 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.

A more likely scenario is that you are hacking in this code and have made silly
errors. It mostly seemed consistent with how the forknum error is reported,
but is not important.

> 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.

No disagreement there, which is why I tried to get it reviewed quickly so it
can be applied and forgotten about and we can move on to more important
matters.

--
Daniel Gustafsson