On Fri, Nov 26, 2021 at 1:42 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > > On 2021-Nov-25, Tom Lane wrote: > >> Really? AFAICS the WAL record contains the correct value, or at least > >> we should define that one as being correct, for precisely this reason. > > > I don't know what is the correct value for a record that comes exactly > > after the page header. But here's a patch that fixes the problem; and > > if a standby replays WAL written by an unpatched primary, it will be > > able to read past instead of dying of FATAL. > > Meh ... but given the simplicity of the write-side fix, maybe changing > it is appropriate. > > However, this seems too forgiving: > > + if (xlrec->overwritten_lsn != state->overwrittenRecPtr && > + xlrec->overwritten_lsn - SizeOfXLogShortPHD != > state->overwrittenRecPtr && > + xlrec->overwritten_lsn - SizeOfXLogLongPHD != > state->overwrittenRecPtr) >
Unless I am missing something, I am not sure why need this adjustment if we are going to use state->currRecPtr value which doesn't seem to be changing at all. AFAICU, state->currRecPtr will be unchanged value whether going to set overwrittenRecPtr or abortedRecPtr. Do primary and standby see state->currRecPtr differently, I guess not, never? Regards, Amul
