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

Alvaro Herrera <alvherre@alvh.no-ip.org>

From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2021-11-05T12:06:50Z
Lists: pgsql-hackers
On 2021-Nov-04, Tom Lane wrote:

> 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.

Yes -- in production settings, it is better to be able to shut down the
standbys in a scheduled manner, than find out after updating the primary
that your standbys are suddenly inaccessible until you take the further
action of updating them.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
Si no sabes adonde vas, es muy probable que acabes en otra parte.



Commits

  1. Repair two portability oversights of new test

  2. Fix WAL replay in presence of an incomplete record

  3. Avoid creating archive status ".ready" files too early