Re: pgsql: Fix WAL replay in presence of an incomplete record

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Fix WAL replay in presence of an incomplete record
Date: 2021-11-05 00:13:50
Message-ID: 364321.1636071230@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

[ I'm working on the release notes ]

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Fix WAL replay in presence of an incomplete record
> ...
> Because a new type of WAL record is added, users should be careful to
> upgrade standbys first, primaries later. Otherwise they risk the standby
> being unable to start if the primary happens to write such a record.

Is there really any point in issuing such advice? IIUC, the standbys
would be unable to proceed anyway in case of a primary crash at the
wrong time, because an un-updated primary would send them inconsistent
WAL. If anything, it seems like it might be marginally better to
update the primary first, reducing the window for it to send WAL that
the standbys will *never* be able to handle. Then, if it crashes, at
least the WAL contains something the standbys can process once you
update them.

Or am I missing something?

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Geoghegan 2021-11-05 02:09:47 pgsql: Add various assertions to heap pruning code.
Previous Message Andrew Dunstan 2021-11-04 16:31:05 Re: pgsql: Fix snapshot reference leak if lo_export fails.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-11-05 00:21:56 Re: inefficient loop in StandbyReleaseLockList()
Previous Message Andres Freund 2021-11-04 23:47:42 Re: WIP: expression evaluation improvements