At Mon, 5 Sep 2022 13:28:12 +1200, Thomas Munro <thomas.mu...@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
