Re: pgsql: Check for conflicting queries during replay ofgistvacuumpage() - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: pgsql: Check for conflicting queries during replay ofgistvacuumpage()
Date
Msg-id 20181221161638.gf6gx3n62dfyvpyn@alvherre.pgsql
Whole thread Raw
In response to Re: pgsql: Check for conflicting queries during replay of gistvacuumpage()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2018-Dec-21, Tom Lane wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Hmmm, I'm fairly sure you should have bumped XLOG_PAGE_MAGIC for this
> > change.  Otherwise, what is going to happen to an unpatched standby (of
> > released versions) that receives the new WAL record from a patched
> > primary?
> 
> We can't change XLOG_PAGE_MAGIC in released branches, surely.
> 
> I think the correct thing is just for the release notes to warn people
> to upgrade standby servers first.

You're right.  My memory is playing tricks on me.  I recalled that we
had done it to prevent replay of WAL replay in nonpatched standbys in
some backpatched commit, but I can't find any evidence of this :-(
The commit message for 8e9a16ab8f7f (in 9.3 branch after it was
released) says:

    In replication scenarios using the 9.3 branch, standby servers must be
    upgraded before their master, so that they are prepared to deal with the
    new WAL record once the master is upgraded; failure to do so will cause
    WAL replay to die with a PANIC message.  Later upgrade of the standby
    will allow the process to continue where it left off, so there's no
    disruption of the data in the standby in any case.  Standbys know how to
    deal with the old WAL record, so it's okay to keep the master running
    the old code for a while.

Stupidly, I checked the 9.4 version of that commit (then the master
branch) and it does indeed contain the XLOG_PAGE_MAGIC change, but the
9.3 commit doesn't.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Check for conflicting queries during replay of gistvacuumpage()
Next
From: Tom Lane
Date:
Subject: Re: START/END line number for COPY FROM