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