Any sense to get rid of known_assigned_xids_lck?

Hello, hackers.

While working on (1) in commit
2871b4618af1acc85665eec0912c48f8341504c4 (2) from 2010 I noticed Simon
Riggs was thinking about usage of memory barrier for KnownAssignedXids
access instead of spinlocks.

> We could dispense with the spinlock if we were to
> create suitable memory access barrier primitives and use those instead.

KnownAssignedXids is array with xids and head/tail pointers. Array is
changed only by startup process. But access to head pointer protected
by spinlock to guarantee new data in array is visible to other CPUs
before head values.

> To add XIDs to the array, we just insert
> them into slots to the right of the head pointer and then advance the head
> pointer.  This wouldn't require any lock at all, except that on machines
> with weak memory ordering we need to be careful that other processors
> see the array element changes before they see the head pointer change.
> We handle this by using a spinlock to protect reads and writes of the
> head/tail pointers.

Now we have memory barriers, so there is an WIP of patch to get rid of
`known_assigned_xids_lck`. The idea is pretty simple - issue
pg_write_barrier after updating array, but before updating head.

First potential positive effect I could see is
(TransactionIdIsInProgress -> KnownAssignedXidsSearch) locking but
seems like it is not on standby hotpath.

Second one - locking for KnownAssignedXidsGetAndSetXmin (build
snapshot). But I was unable to measure impact. It wasn’t visible
separately in (3) test.

Maybe someone knows scenario causing known_assigned_xids_lck or
TransactionIdIsInProgress become bottleneck on standby?

Best regards,
Michail.

[1]:
https://www.postgresql.org/message-id/flat/CANtu0ohzBFTYwdLtcanWo4%2B794WWUi7LY2rnbHyorJdE8_ZnGg%40mail.gmail.com#379c1be7b8134ada5a574078d51b64c6

[2]:
https://github.com/postgres/postgres/commit/2871b4618af1acc85665eec0912c48f8341504c4#diff-8879f0173be303070ab7931db7c757c96796d84402640b9e386a4150ed97b179R2409

[3]:
https://www.postgresql.org/message-id/flat/CANtu0ohzBFTYwdLtcanWo4%2B794WWUi7LY2rnbHyorJdE8_ZnGg%40mail.gmail.com#379c1be7b8134ada5a574078d51b64c6