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
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 |