From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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 12:06:50 |
Message-ID: | 202111051206.tcvp24m6fxyr@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-11-05 12:28:16 | Re: pgsql: Fix WAL replay in presence of an incomplete record |
Previous Message | Michael Paquier | 2021-11-05 06:48:25 | Re: pgsql: Add various assertions to heap pruning code. |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2021-11-05 12:07:21 | Re: [PATCH] rename column if exists |
Previous Message | Isaac Morland | 2021-11-05 12:03:58 | Re: [PATCH] rename column if exists |