Hi,
When testing streaming replication with a physical slot. I found an unexpected
behavior that the walsender could use an invalidated physical slot for
streaming.
This occurs when the primary slot is invalidated due to reaching the
max_slot_wal_keep_size before initializing the streaming replication
(e.g. before creating the standby). Attach a draft script(test_invalidated_slot.sh)
which can reproduce this.
Once the slot is invalidated, it can no longer protect the WALs and
Rows, as these invalidated slots are not considered in functions like
ReplicationSlotsComputeRequiredXmin().
Besides, the walsender could advance the restart_lsn of an invalidated slot,
then user won't be able to know that if the slot is actually validated or not,
because the 'conflicting' of view pg_replication_slot could be set back to
null.
So, I think it's a bug and one idea to fix is to check the validity of the physical slot in
StartReplication() after acquiring the slot like what the attachment does,
what do you think ?
Best Regards,
Hou Zhijie