Re: sync_standbys_defined read/write race on startup
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: "Maksim.Melnikov" <m.melnikov@postgrespro.ru>
Cc: Kirill Reshke <reshkekirill@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-04-10T09:15:37Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix race with synchronous_standby_names at startup
- e2f42f812a80 13.21 landed
- 873aff945a7b 14.18 landed
- ec59500a1740 15.13 landed
- c922ae2c42a6 16.9 landed
- 3339847ccde0 17.5 landed
- 2e57790836c6 18.0 landed
Attachments
- v6-0001-Fix-sync_standbys_defined-race-on-startup.patch (text/x-diff) patch v6-0001
On Thu, Apr 10, 2025 at 10:12:34AM +0300, Maksim.Melnikov wrote:
> but I am afraid we are loosing this.
>
> if (WalSndCtl->sync_standbys_status & SYNC_STANDBY_INIT)
> {
> if ((WalSndCtl->sync_standbys_status & SYNC_STANDBY_DEFINED) == 0 ||
> lsn <= WalSndCtl->lsn[mode])
> {
> LWLockRelease(SyncRepLock);
> return;
> }
> }
> [...]
> + else if (lsn <= WalSndCtl->lsn[mode])
> + {
> + LWLockRelease(SyncRepLock);
> + return;
> + }
>
> What do you think?
Hmm, yeah. Instead of last, it would be better to put it in second
place perhaps, for clarity? That would be the same at the end, but we
would be slightly more consistent with the past logic regarding the
ordering. Does that look OK to you?
--
Michael