Horton

Re: [BUG] Panic due to incorrect missingContrecPtr after promotion

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, "Imseih (AWS), Sami" <simseih@amazon.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-06-22T14:38:55Z
Lists: pgsql-hackers 
On Mon, Jun 20, 2022 at 9:35 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> Unfortunately it doesn't work because we read a record already known
> to be complete again at the end of recovery.  It is the reason of
> "abortedRecPtr < xlogreader->EndRecPtr" in my PoC patch.  Without it,
> abrotedRecPtr is erased when it is actually needed.  I don't like that
> expedient-looking condition, but the strict condition for resetting
> abortedRecPtr is iff "we have read a complete record at the same or
> grater LSN ofabortedRecPtr"...

Yeah, we need to work around that somehow. I noticed the
record-rereading behavior when I was working on some patches for this
release cycle and I think what we ought to do is get rid of that. It
serves no purpose other than to make things complicated. However, we
shouldn't back-patch a change like that, I think, so we'll need to
work around the issue somehow. Perhaps it'd be better to return these
values to the caller somehow and then the caller can decide whether to
save them based on context. The last re-read can choose not to do so.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Prevent WAL corruption after a standby promotion.

  2. Fix "missing continuation record" after standby promotion