Re: old_snapshot_threshold bottleneck on replica

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Maxim Orlov <orlovmg(at)gmail(dot)com>
Cc: Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: old_snapshot_threshold bottleneck on replica
Date: 2023-01-27 15:17:51
Message-ID: CA+TgmoYOZOU0gyJKLdjudxiEjXEgtvNpeLqoivv6bjVJJHRrFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 27, 2023 at 9:30 AM Maxim Orlov <orlovmg(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2023-01-27 15:18:41 Re: Lazy JIT IR code generation to increase JIT speed with partitions
Previous Message Andrew Dunstan 2023-01-27 14:57:45 Re: run pgindent on a regular basis / scripted manner