Re: Replace known_assigned_xids_lck by memory barrier - Mailing list pgsql-hackers

From Michail Nikolaev
Subject Re: Replace known_assigned_xids_lck by memory barrier
Date
Msg-id CANtu0ogdo86z-+oQVT7LENPPe_W4N5Q4HsisM_Xpf-H=v5vaow@mail.gmail.com
Whole thread Raw
In response to Re: Replace known_assigned_xids_lck by memory barrier  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Replace known_assigned_xids_lck by memory barrier
List pgsql-hackers
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.

Attachment

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: should frontend tools use syncfs() ?
Next
From: jian he
Date:
Subject: Re: Extract numeric filed in JSONB more effectively