> On 14 Jul 2026, at 00:17, Robert Haas <[email protected]> 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
