Re: Race condition in SyncRepGetSyncStandbysPriority

At Fri, 17 Apr 2020 17:03:11 +0900, Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote in 
> On Fri, 17 Apr 2020 at 14:58, Kyotaro Horiguchi <horikyota.ntt@gmail.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