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

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

  1. Replace known_assigned_xids_lck with memory barriers.

  2. Replace the KnownAssignedXids hash table with a sorted-array data structure,