Re: Better Upgrades - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Better Upgrades
Date
Msg-id CAKFQuwZ97pGDdJ1iMZDNcVUg6TjoAG+QgUyPMco=-jJxgr5Z9Q@mail.gmail.com
Whole thread Raw
In response to Better Upgrades  (David Fetter <david@fetter.org>)
List pgsql-hackers
On Mon, Feb 5, 2018 at 5:09 PM, David Fetter <david@fetter.org> wrote:

The proposal has blockers:

- We don't actually have logical decoding for DDL, although I'm given
  to understand that Álvaro Herrera has done some yeoman follow-up
  work on Dimitri Fontaine's PoC patches.
- We don't have logical decoding for DCL (GRANT/REVOKE)

We also came up with and, we believe, addressed an important issue,
namely how to ensure continuity.  When we issue a `pg_ctl stop -w`,
that's short for "Cancel current commands and stop cleanly."  At this
point, the new server will not have WAL to replay, so a pg_ctl restart
will load the new configuration and come up pretty much immediately,
and the next try will find a brand new server without a down time
event.

To what extent do people think that differing cache contents between the primary and secondary are likely to play a role?  While connection downtime is zero as long as people have their fail-and-reconnect logic in place queries taking longer than expected do to unexpected disk I/O could cause SLA problems.​  pg_prewarm currently fulfills that role, and maybe it isn't the large a problem in practice (the scale I operate at doesn't have this concern), but having some kind of channel to keep cached blocks (at least within PostgreSQL) synchronized would probably be something to at least factor into the design even if the first pass didn't solve that particular problem.

David J.


Dave

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Better Upgrades
Next
From: Tomas Vondra
Date:
Subject: Re: WIP: BRIN multi-range indexes