Hi, On 2023-01-19 10:43:27 +0100, Drouvot, Bertrand wrote: > > > With a reload in place in my testing, now I notice that the catalog_xmin > > > is updated on the primary physical slot after logical slots invalidation > > > when reloading hot_standby_feedback from "off" to "on". > > > > > > This is not the case after a re-start (aka catalog_xmin is NULL). > > > > > > I think a re-start and reload should produce identical behavior on > > > the primary physical slot. If so, I'm tempted to think that the > > > catalog_xmin > > > should be updated in case of a re-start too (even if all the logical > > > slots are invalidated) > > > because the slots are not dropped yet. What do you think? > > > > I can't quite follow the steps leading up to the difference. Could you list > > them in a bit more detail? > > > > > > 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? 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? If that isn't it, something is broken in InvalidateObsolete... > No, but a question still remains to me: > > Given the fact that the row removal case is already done > in the next test (aka Scenario 2), If we want to replace the "vacuum full" > test > on the database (done in Scenario 1) with a cheaper one at the table level, > what could it be to guarantee an invalidation? > > Same as scenario 2 but with "vacuum full pg_class" would not really add value > to the tests, right? A database wide VACUUM FULL is also just a row removal test, no? I think it makes sense to test that both VACUUM and VACUUM FULL both trigger conflicts, because they internally use *very* different mechanisms. It'd probably be good to test at least conflicts triggered due to row removal via on-access pruning as well. And perhaps also for btree killtuples. I think those are the common cases for catalog tables. Greetings, Andres Freund
