Re: Replace known_assigned_xids_lck by memory barrier
Michail Nikolaev <michail.nikolaev@gmail.com>
From: Michail Nikolaev <michail.nikolaev@gmail.com>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
Tom Lane <tgl@sss.pgh.pa.us>
Date: 2023-08-16T15:30:59Z
Lists: pgsql-hackers
Attachments
- v3-0001-Removes-known_assigned_xids_lck-using-the-write-m.patch (text/x-patch) patch v3-0001
Hello! Updated version (with read barriers is attached). > One remaining question I have is whether it is okay if we see an updated value > for one of the head/tail variables but not the other. It looks like the > tail variable is only updated with ProcArrayLock held exclusively, which > IIUC wouldn't prevent such mismatches even today, since we use a separate > spinlock for reading them in some cases. 1) "The convention is that backends must hold shared ProcArrayLock to examine the array", it is applied to pointers as well 2) Also, "only the startup process modifies the head/tail pointers." So, the "tail" variable is updated by the startup process with ProcArrayLock held in exclusive-only mode - so, no issues here. Regarding "head" variable - updates by the startup processes are possible in next cases: * ProcArrayLock in exclusive mode (like KnownAssignedXidsCompress or KnownAssignedXidsSearch(remove=true)), no issues here * ProcArrayLock not taken at all (like KnownAssignedXidsAdd(exclusive_lock=false)) in such case we rely on memory barrier machinery Both head and tail variables are changed only with exclusive lock held. I'll think more, but can't find something wrong here so far.
Commits
-
Replace known_assigned_xids_lck with memory barriers.
- 119c23eb9819 17.0 landed
-
Replace the KnownAssignedXids hash table with a sorted-array data structure,
- 2871b4618af1 9.0.0 cited