Re: physical slot xmin dependency on logical slot?

>
> I expect that you created the replica in a manner that preserved the
> logical replication slot on it. You also had hot_standby_feedback enabled.
>

As per both you and Andres' replies, we wanted the backup to have the
logical slots on it, because we wanted to allow decoding from the slots on
our backup. However, what we should have done is drop the slot of the
backup on the master.

> PostgreSQL standbys send the global xmin and (in Pg10+) catalog_xmin to
> the upstream when hot_standby_feedback is enabled. If there's a slot
> holding the catalog_xmin on the replica down, that'll be passed on via
> hot_standby_feedback to the upstream. On Pg 9.6 or older, or if the replica
> isn't using a physical replication slot, the catalog_xmin is treated as a
> regular xmin since there's nowhere in PGPROC or PGXACT to track the
> separate catalog_xmin. If the standby uses a physical slot, then on pg10+
> the catalog_xmin sent by the replica is stored as the catalog_xmin on the
> physical slot instead.
>
> Either way, if you have hot_standby_feedback enabled on a standby, that
> feedback includes the requirements of any replication slots on the standby.
>

Thank you for the thorough explanation. As I noted in my reply to Andres,
we routinely and intentionally create snapshots with replication slots
intact (but we normally drop the slot on the master immediately), so our
own use case is rare and it's not surprising that we don't find a thorough
explanation of this scenario in the docs.

Thanks,
Jeremy