Re: Race condition in SyncRepGetSyncStandbysPriority
Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
From: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
Fujii Masao <masao.fujii@oss.nttdata.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-04-20T05:35:23Z
Lists: pgsql-hackers
On Sun, 19 Apr 2020 at 01:00, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Masahiko Sawada <masahiko.sawada@2ndquadrant.com> writes: > > On Sat, 18 Apr 2020 at 00:31, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> + /* Quick out if not even configured to be synchronous */ > >> + if (SyncRepConfig == NULL) > >> + return false; > > > I felt strange a bit that we do the above check in > > SyncRepGetSyncRecPtr() because SyncRepReleaseWaiters() which is the > > only caller says the following before calling it: > > Notice there was such a test in SyncRepGetSyncRecPtr already --- I just > moved it to be before doing some work instead of after. > > > Can we either change it to an assertion, move it to before acquiring > > SyncRepLock in SyncRepReleaseWaiters or just remove it? > > I have no objection to that in principle, but it seems like it's a > change in SyncRepGetSyncRecPtr's API that is not necessary to fix > this bug. So I'd rather leave it to happen along with the larger > API changes (getting rid of am_sync) that are proposed for v14. Agreed. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Fix race conditions in synchronous standby management.
- c65c1aa82105 9.6.18 landed
- f332241a60aa 13.0 landed
- b3fa6d016d82 11.8 landed
- 63ecdaf758c5 10.13 landed
- 00ef5d52c577 12.3 landed
-
When WalSndCaughtUp, sleep only in WalSndWaitForWal().
- 421685812290 13.0 cited