> I might be missing something but isn’t it okay even if the new primary
> server is behind the subscribers? IOW, even if two slot's LSNs (i.e.,
> restart_lsn and confirm_flush_lsn) are behind the subscriber's remote
> LSN (i.e., pg_replication_origin.remote_lsn), the primary sends
Hello,
The doc mentions that standby_slot_names is to only be used for waiting on
physical slots. However, it seems like we calculate the flush_pos for logical
slots as well in wait_for_standby_confirmation?
Re-posting some of my previous comment since it seems like it got lost...
In
Hello,
I started taking a brief look at the v2 patch, and it does appear to work for
the basic case. Logical slot is synchronized across and I can connect to the
promoted standby and stream changes afterwards.
It's not clear to me what the correct behavior is when a logical slot that has
been
:44:30 +, "Hsu, John" wrote in
> Hi hackers,
>
> We believe we’re seeing a problem with how physical slot’s restart_lsn is
> advanced leading to the replicas needing to restore from archive in order for
> replication to resume.
> The logs below are from repr
