> On 11-Aug-2020, at 8:57 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> I think this gets to the root of the issue. If we check the flag
> without a lock, we might see a slightly stale value. But, considering
> that there's no particular amount of time within which configuration
> changes are guaranteed to take effect, maybe that's OK. However, there
> is one potential gotcha here: if the walsender declares the standby to
> be synchronous, a user can see that, right? So maybe there's this
> problem: a user sees that the standby is synchronous and expects a
> transaction committing afterward to provoke a wait, but really it
> doesn't. Now the user is unhappy, feeling that the system didn't
> perform according to expectations.
Yes, pg_stat_replication reports a standby in sync as soon as walsender updates priority of the standby to something
otherthan 0.
The potential gotcha referred above doesn’t seem too severe. What is the likelihood of someone setting
synchronous_standby_namesGUC with either “*” or a standby name and then immediately promoting that standby? If the
standbyis promoted before the checkpointer on master gets a chance to update sync_standbys_defined in shared memory,
commitsmade during this interval on master may not make it to standby. Upon promotion, those commits may be lost.
Asim