Re: BUG #19599: RestoreBlockImage: the decode cross-checks never bound hole_offset + hole_length against BLCKSZ - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: BUG #19599: RestoreBlockImage: the decode cross-checks never bound hole_offset + hole_length against BLCKSZ
Date
Msg-id ar2hA_b1Be7VsZdP@paquier.xyz
Whole thread
In response to Re: BUG #19599: RestoreBlockImage: the decode cross-checks never bound hole_offset + hole_length against BLCKSZ  (Grigorev Jurij <ju.grigorev@ftdata.ru>)
Responses Re: BUG #19599: RestoreBlockImage: the decode cross-checks never bound hole_offset + hole_length against BLCKSZ
List pgsql-hackers
On Tue, Sep 29, 2026 at 08:37:02AM +0000, Grigorev Jurij wrote:
> Thank you very much for the thorough review and testing -- the
> crash-recovery matrix (pglz/lz4/zstd/off + consistency checking) and
> especially the crafted-record repro with pg_waldump --save-fullpage
> crashing without the patch are super convincing. And thanks for
> confirming the back-patch safety argument.
>
> v2 attached, addressing all your points:

XLogRecordAssemble() in xloginsert.c enforces a size policy already
when a page image needs to be included in a record (REGBUF_STANDARD
case, for both the "lower" and "upper" cases).  The argument of a
corrupted record does not stand, a CRC32 check would complain before
we ever reach this path.  The hand-made record record argument is also
something I have a hard time to buy, because WAL data is trusted.

So, I don't understand what this patch buys us at all, except more
complexity in the replay path.

There may be an argument for the xlogreader facility, but this relies
on the premise that incorrect WAL records are a thing out there.
Again here comes the CRC check in the record header and the WAL
insertion enforcing already some bounds.  This feels like test bloat
to me.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [PATCH] intXshr, intXshl: return error on shift count out of range
Next
From: Henson Choi
Date:
Subject: Re: Row pattern recognition