Re: Race condition in SyncRepGetSyncStandbysPriority

At Fri, 17 Apr 2020 17:03:11 +0900, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote in
> On Fri, 17 Apr 2020 at 14:58, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
> > The attached is baed on syncrep-fixes-1.patch + am_sync elimination.
> >
>
> Just for confirmation, since the new approach doesn't change that
> walsenders reload new config at their convenient timing, it still can
> happen that a walsender releases waiters according to the old config
> that defines fewer number of sync standbys, during walsenders

Right.

> absorbing a change in the set of synchronous walsenders. In the worst
> case where the master crashes in the middle, we cannot be sure how
> many sync servers the data has been replicated to. Is that right?

Wal senders can set a stupid value as priority or in a worse case the
shared walsender information might be of another walsender that is
launched just now. In any case SyncRepGetSyncStandbys can return a set
of walsenders with descending priority (in priority mode). What can
be happen in the worst case is some transactions are released by a bit
wrong LSN information. Such inconsistency also can be happen when the
oldest sync standby in priority mode goes out and sync-LSN goes back
even if the wal-sender list is strictly kept consistent.

In quorum mode, we cannot even know which servers that endorsed the
master's commit after a crash.

I don't come up of clean solution for such inconsistency or
unrecoverability(?) for now..

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center