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

From Alexander Korotkov
Subject Re: pgsql: Check for conflicting queries during replay of gistvacuumpage()
Date
Msg-id CAPpHfdsS1LSO7cMa_rpdNZXUYNESHQa4mA9_kJhLemN99ZG=BQ@mail.gmail.com
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 Fri, Dec 21, 2018 at 7:09 PM Tom Lane <tgl@sss.pgh.pa.us> 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?
>
> Oh, and if the answer to your question is not "it fails with an
> intelligible error about an unrecognized WAL record type", then we
> need to adjust what is emitted so that that will be what happens.
> Crashing, or worse silently misprocessing the record, will not do.

Please, note that backpatched version takes special efforts to not
introduce new WAL record type. Unpatched standby applies WAL stream of
patched primary without any errors, but ignoring conflicts (as it was
before) [1].  Patched standby applies the same WAL stream with
conflict handling.  And I've briefly mentioned that in commit message.

"On stable releases we've to be tricky to keep WAL compatibility.
Information required for conflict processing is just appended to data
of XLOG_GIST_PAGE_UPDATE record.  So, PostgreSQL version, which
doesn't know about conflict processing, will just ignore that."

The thing we can mention in the release notes is that both primary and
standby should be upgraded to get conflict handling.  If one of them
is not upgraded, conflicts will be still missed.

Links:
1. https://www.postgresql.org/message-id/CAPpHfdsKS0K8q1sJ-XyMrU%3DL%2Be6XSAOgS09NXp1bQDQts%2Bqz%2Bg%40mail.gmail.com

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Change pgarch_readyXlog() to return .history files first
Next
From: Tom Lane
Date:
Subject: Re: Joins on TID