Re: Minimal logical decoding on standbys

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