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:28:16Z
Lists: pgsql-hackers
On 2021-Nov-05, Alvaro Herrera wrote:
> On 2021-Nov-04, Tom Lane wrote:
>
> > 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.
I suppose the strategy is useless if the primary never crashes. If the
situation does occur, users can handle it the same way they've handled
it thus far: manually delete the segment from the standby and restart.
At least they know what to do and may even have already automated it.
The other situation is new and would need somebody, possibly taken
abruptly from their sleep, to try to understand why their standbys
refuse to proceed replication in a novel way.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Porque Kim no hacía nada, pero, eso sí,
con extraordinario éxito" ("Kim", Kipling)
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