Re: Race condition in SyncRepGetSyncStandbysPriority - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Race condition in SyncRepGetSyncStandbysPriority
Date
Msg-id 20200413.153424.688075393737383141.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Race condition in SyncRepGetSyncStandbysPriority  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Race condition in SyncRepGetSyncStandbysPriority
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: pg_validatebackup -> pg_verifybackup?