Re: Bug: XLogReader mishandles oversized multi-page xl_tot_len (potential memory corruption) - Mailing list pgsql-hackers

On Mon, 3 Aug 2026 at 01:21, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Sun, Aug 02, 2026 at 04:08:17PM +0900, Michael Paquier wrote:
> > -       newSize += XLOG_BLCKSZ - (newSize % XLOG_BLCKSZ);
> > +       Assert(reclength <= INT32_MAX - BLCKSZ);
> > +
> > +       newSize = TYPEALIGN(XLOG_BLCKSZ, reclength);
> >
> > Am I reading a typo here or the INT32_MAX is missing a 'PG_U'?
> > XLogRecordMaxSize cannot reach that, just wondering about a
> > consistency argument with the surrounding type declarations for these
> > length variables.

Yes, that was an oversight in my submission.
It's been changed to XLogRecordMaxSize, with a new comment, in the
attached patch.

> Another thing to note: this basically breaks the recovery test
> 039_end_of_wal.pl.  Could you look at that please?

Also fixed, including a new test case for >XLogRecordMaxSize.

-Matthias