Any sense to get rid of known_assigned_xids_lck? - Mailing list pgsql-hackers

From Michail Nikolaev
Subject Any sense to get rid of known_assigned_xids_lck?
Date
Msg-id CANtu0ojxDMxUyy-GgyGr+RMqbZ=LpEJBm=vhPwUY2756aJMBnA@mail.gmail.com
Whole thread Raw
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Improve TAP tests of pg_upgrade for cross-version tests
Next
From: Amit Langote
Date:
Subject: Re: Replica Identity check of partition table on subscriber