Re: old_snapshot_threshold bottleneck on replica - Mailing list pgsql-hackers

From Robert Haas
Subject Re: old_snapshot_threshold bottleneck on replica
Date
Msg-id CA+TgmoYOZOU0gyJKLdjudxiEjXEgtvNpeLqoivv6bjVJJHRrFg@mail.gmail.com
Whole thread Raw
In response to Re: old_snapshot_threshold bottleneck on replica  (Maxim Orlov <orlovmg@gmail.com>)
Responses Re: old_snapshot_threshold bottleneck on replica
List pgsql-hackers
On Fri, Jan 27, 2023 at 9:30 AM Maxim Orlov <orlovmg@gmail.com> wrote:
> I thank you for your advices. I've dived deeper into the problem and I think v2 patch is wrong.

Cool!

> Accessing threshold_timestamp and threshold_xid in TransactionIdLimitedForOldSnapshots
> without lock would lead to an improper xlimit calculation.

That would be a bummer.

> So, my choice would be (3b). My goal is to optimize access to the threshold_timestamp to avoid
> multiple spinlock acquisition on read. In the same time, simultaneous access to these variable
> (threshold_timestamp and threshold_xid) should be protected with spinlock.
>
> I remove atomic for threshold_xid and add comments on mutex_threshold. PFA, v3. I

Interesting, but it's still not entirely clear to me from reading the
comments why we should think that this is safe.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: run pgindent on a regular basis / scripted manner
Next
From: Dmitry Dolgov
Date:
Subject: Re: Lazy JIT IR code generation to increase JIT speed with partitions