Re: pg15b3: recovery fails with wal prefetch enabled
От | Kyotaro Horiguchi |
---|---|
Тема | Re: pg15b3: recovery fails with wal prefetch enabled |
Дата | |
Msg-id | 20220905.141527.1307117225838638990.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: pg15b3: recovery fails with wal prefetch enabled (Thomas Munro <thomas.munro@gmail.com>) |
Список | 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
В списке pgsql-hackers по дате отправления: