Hi,
On 12/12/2018 21:41, Andres Freund wrote:
>
> I don't like the approach of managing the catalog horizon via those
> periodically logged catalog xmin announcements. I think we instead
> should build ontop of the records we already have and use to compute
> snapshot conflicts. As of HEAD we don't know whether such tables are
> catalog tables, but that's just a bool that we need to include in the
> records, a basically immeasurable overhead given the size of those
> records.
IIRC I was originally advocating adding that xmin announcement to the
standby snapshot message, but this seems better.
>
> If we were to go with this approach, there'd be at least the following
> tasks:
> - adapt tests from [2]
> - enforce hot-standby to be enabled on the standby when logical slots
> are created, and at startup if a logical slot exists
> - fix issue around btree_xlog_delete_get_latestRemovedXid etc mentioned
> above.
> - Have a nicer conflict handling than what I implemented here. Craig's
> approach deleted the slots, but I'm not sure I like that. Blocking
> seems more appropriately here, after all it's likely that the
> replication topology would be broken afterwards.
> - get_rel_logical_catalog() shouldn't be in lsyscache.[ch], and can be
> optimized (e.g. check wal_level before opening rel etc).
>
>
> Once we have this logic, it can be used to implement something like
> failover slots on-top, by having having a mechanism that occasionally
> forwards slots on standbys using pg_replication_slot_advance().
>
Looking at this from the failover slots perspective. Wouldn't blocking
on conflict mean that we stop physical replication on catalog xmin
advance when there is lagging logical replication on primary? It might
not be too big deal as in that use-case it should only happen if
hs_feedback was off at some point, but just wanted to point out this
potential problem.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services