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
-
Repair two portability oversights of new test
- e3731bac52cf 14.1 landed
- d03bca4d70c2 15.0 landed
-
Fix WAL replay in presence of an incomplete record
- ff9f111bce24 15.0 cited
-
Avoid creating archive status ".ready" files too early
- 515e3d84a0b5 15.0 cited