Hi Surya, Thanks for the review, and for testing on 19 and master. Your recovery_prefetch numbers show the problem much better than mine did.
v2 attached: - 0001's commit message now says that with recovery_prefetch the message can name any record in the read-ahead window, with your redo start point as the example, and that pg_walinspect reports the same messages (your point 3). - It also says the WAL_DEBUG messages now show the end of the inserted record, where they printed 0/00000000 before (point 1). - 0001 adds a test to pg_waldump's 001_basic.pl (point 2). It updates a row right after a checkpoint, so that the update record carries a full-page image with a hole, clears the hole offset in a copy of the WAL segment, and recomputes the record's CRC with crc32c(). It then checks that pg_waldump names that record, both when started before it and when started at it, your second pg_waldump case. 0002 extends it to check the "error in WAL record at" prefix too. Without the fixes, those checks fail. Thanks for offering your script. Recomputing the CRC with crc32c() kept the test short, but that function only exists from 18 on, so the test can't go back further than that with 0001. Regards, Rahul Yadav
v2-0002-pg_waldump-Report-the-position-of-a-WAL-read-erro.patch
Description: Binary data
v2-0001-Report-the-decoded-record-s-LSN-in-DecodeXLogReco.patch
Description: Binary data
