Hi Ashutosh, On Wed, Feb 25, 2026 at 11:42 PM Ashutosh Sharma <[email protected]> wrote:
> > I don't think we should be comparing "synchronous_standby_names" with > "synchronized_standby_slots", even though they appear similar in > purpose. All values listed in synchronous_standby_names represent > synchronous standbys exclusively, whereas synchronized_standby_slots > can hold values for both synchronous and asynchronous standbys. In > other words, every server referenced by synchronous_standby_names is > of the same type, but that may not be the case with > synchronized_standby_slots. > > If a GUC can hold values of different types (sync vs. async), does it > really make sense to use a qualifier like ANY 1 (val1, val2) when val1 > and val2 are different in nature? For example, suppose val1 is a > synchronous standby and val2 is an asynchronous standby, and we > configure ANY 1 (val1, val2). It's possible for val2 to get ahead of > val1 in terms of replication progress, which in turn could mean the > logical replica is also ahead of val1. So if we were to fail over to > val1 (since it's the only synchronous standby), we will not be able to > use the existing logical replication setup. > If the failover orchestrator cannot ensure standby1 to not get the quorum committed WAL (from archive or standby2) then the setting ANY 1 (val1, val2) is invalid. This setup also has issues because in your scenario, standby2 is ahead of the new primary (standby1) and standby2 requires now to rewind to be in sync with the new primary. Additionally, it allowed readers to read data that was lost at the end of the failover. We ideally need a mechanism to not send WAL to async replicas before the sync replicas commit (honoring syncrhnous_standby_names GUC) feature (similar to synchronized_standby_slots). It could be a different thread on its own.
