Re: Race condition in SyncRepGetSyncStandbysPriority

At Mon, 13 Apr 2020 15:31:01 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> At Sat, 11 Apr 2020 18:30:30 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in 
> > The point that I was trying to make originally is that it seems quite
> > insane to imagine that a walsender's sync_standby_priority value is
> > somehow more stable than the very existence of the process.  Yet we
> > only require a walsender to lock its own mutex while claiming or
> > disowning its WalSnd entry (by setting or clearing the pid field).
> > So I think it's nuts to define those fields as being protected by
> > the global SyncRepLock.
> 
> Right. FWIW, furthermore, even SyncRepConfig->syncrep_method can be
> inconsistent among walsenders.  I haven't thought that it can be
> relied on as always consistent and it is enough that it makes a
> consistent result only while the setting and the set of walsenders is
> stable.

Yes, the sentene "and (I haven't thought that) it is enough .." is a
mistake of "and I have thought that it is enough that..".

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center