Hi,
On 1/24/23 6:20 AM, Drouvot, Bertrand wrote:
Hi,
On 1/24/23 1:46 AM, Andres Freund wrote:
Hi,
On 2023-01-19 10:43:27 +0100, Drouvot, Bertrand wrote:
Sure, so with:
1) hot_standby_feedback set to off on the standby
2) create 2 logical replication slots on the standby and activate one
3) Invalidate the logical slots on the standby with VACUUM FULL on the primary
4) change hot_standby_feedback to on on the standby
If:
5) pg_reload_conf() on the standby, then on the primary we get a catalog_xmin
for the physical slot that the standby is attached to:
postgres=# select slot_type,xmin,catalog_xmin from pg_replication_slots ;
slot_type | xmin | catalog_xmin
-----------+------+--------------
physical | 822 | 748
(1 row)
How long did you wait for this to change?
Almost instantaneous after pg_reload_conf() on the standby.
I don't think there's anything right
now that'd force a new hot-standby-feedback message to be sent to the primary,
after slots got invalidated.
I suspect that if you terminated the walsender connection on the primary,
you'd not see it anymore either?
Still there after the standby is shutdown but disappears when the standby is
re-started.
If that isn't it, something is broken in InvalidateObsolete...
Yeah, you are right: ReplicationSlotsComputeRequiredXmin() is missing for the
logical slot invalidation case (and ReplicationSlotsComputeRequiredXmin() also
needs to take care of it).
I'll provide a fix in the next revision along with the TAP tests comments
addressed.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
