Re: Synchronizing slots from primary to standby

Hi,

On Fri, Mar 29, 2024 at 01:06:15AM +0000, Zhijie Hou (Fujitsu) wrote:
> Attach a new version patch which fixed an un-initialized variable issue and
> added some comments. Also, temporarily enable DEBUG2 for the 040 tap-test so that
> we can analyze the possible CFbot failures easily.
>

Thanks!

+ if (remote_slot->confirmed_lsn != slot->data.confirmed_flush)
+ {
+ /*
+ * By advancing the restart_lsn, confirmed_lsn, and xmin using
+ * fast-forward logical decoding, we ensure that the required snapshots
+ * are saved to disk. This enables logical decoding to quickly reach a
+ * consistent point at the restart_lsn, eliminating the risk of missing
+ * data during snapshot creation.
+ */
+ pg_logical_replication_slot_advance(remote_slot->confirmed_lsn,
+ found_consistent_point);
+ ReplicationSlotsComputeRequiredLSN();
+ updated_lsn = true;
+ }

Instead of using pg_logical_replication_slot_advance() for each synced slot
and during sync cycles what about?:

- keep sync slot synchronization as it is currently (not using pg_logical_replication_slot_advance())
- create "an hidden" logical slot if sync slot feature is on
- at the time of promotion use pg_logical_replication_slot_advance() on this
hidden slot only to advance to the max lsn of the synced slots

I'm not sure that would be enough, just asking your thoughts on this (benefits
would be to avoid calling pg_logical_replication_slot_advance() on each sync slots
and during the sync cycles).

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com