Re: pg15b3: recovery fails with wal prefetch enabled - Mailing list pgsql-hackers

At Mon, 5 Sep 2022 13:28:12 +1200, Thomas Munro <thomas.munro@gmail.com> wrote in 
> I had this more or less figured out on Friday when I wrote last, but I
> got stuck on a weird problem with 026_overwrite_contrecord.pl.  I
> think that failure case should report an error, no?  I find it strange
> that we end recovery in silence.  That was a problem for the new
> coding in this patch, because it is confused by XLREAD_FAIL without
> queuing an error, and then retries, which clobbers the aborted recptr
> state.  I'm still looking into that.

+1 for showing any message for the failure, but I think we shouldn't
hide an existing message if any. And the error messages around are
just telling that "<some error happened> at RecPtr". So I think
"missing contrecord at RecPtr" is sufficient here.

diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index cdcacc7803..bfe332c014 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -907,6 +907,11 @@ err:
                 */
                state->abortedRecPtr = RecPtr;
                state->missingContrecPtr = targetPagePtr;
+
+               /* Put a generic error message if no particular cause is recorded. */
+               if (!state->errormsg_buf[0])
+                       report_invalid_record(state, "missing contrecord at %X/%X",
+                                                                 LSN_FORMAT_ARGS(RecPtr));
        }
 
        if (decoded && decoded->oversized)

-- 
Kyotaro Horiguchi
NTT Open Source Software Center