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.