Hi Masahiko,
On Fri, 14 Nov 2025 at 23:32, Masahiko Sawada <[email protected]> wrote:
> Given the current behavior that we cannot create a logical slot with
> failover=true on the standby, it makes sense to me that we overwrite
> the pre-existing slot (with synced=false and failover=true) on the old
> primary by the slot (with synced=true and failover=true) on the new
> primary if their names, plugin and other properties matches and the
> pre-existing slot has lesser LSNs and XIDs than the one on the new
> primary.
>From one side the idea to have additional checks looks reasonable, but if I
look at existing update_local_synced_slot() function, I find the following:
if (remote_dbid != slot->data.database ||
remote_slot->two_phase != slot->data.two_phase ||
remote_slot->failover != slot->data.failover ||
strcmp(remote_slot->plugin, NameStr(slot->data.plugin)) != 0 ||
remote_slot->two_phase_at != slot->data.two_phase_at)
{
NameData plugin_name;
/* Avoid expensive operations while holding a spinlock. */
namestrcpy(&plugin_name, remote_slot->plugin);
SpinLockAcquire(&slot->mutex);
slot->data.plugin = plugin_name;
slot->data.database = remote_dbid;
slot->data.two_phase = remote_slot->two_phase;
slot->data.two_phase_at = remote_slot->two_phase_at;
slot->data.failover = remote_slot->failover;
SpinLockRelease(&slot->mutex);
That is, if some synced slot properties on standby don't match with the
primary we simply overwrite them.
I guess this is necessary because synchronization happens only
periodically, and between two runs a slot on the primary might have been
recreated with different properties.
Do we really need to have additional checks to flip a synced flag?
Regards,
--
Alexander Kukushkin
