Postgres Pro
Downloads
Home   >   mailing lists

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

From Maxim Orlov
Subject Re: old_snapshot_threshold bottleneck on replica
Date
Msg-id CACG=ezbs6pHddXtGpdaCm+VT_2BQsu53OVZLjYVPc9ABRAaaQg@mail.gmail.com
Whole thread Raw
In response to Re: old_snapshot_threshold bottleneck on replica  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: old_snapshot_threshold bottleneck on replica
List pgsql-hackers
Tree view

On Wed, 25 Jan 2023 at 16:52, Robert Haas <robertmhaas@gmail.com> wrote:
On Wed, Jan 25, 2023 at 3:52 AM Maxim Orlov <orlovmg@gmail.com> wrote:

Well, that's something we - and ideally you, as the patch author -
need to analyze and figure out. We can't just take a shot and hope for
the best.
 
I thank you for your advices. I've dived deeper into the problem and I think v2 patch is wrong.
Accessing threshold_timestamp and threshold_xid in TransactionIdLimitedForOldSnapshots
without lock would lead to an improper xlimit calculation.

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

--
Best regards,
Maxim Orlov.
Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: SQL/JSON revisited
Next
From: vignesh C
Date:
Subject: Re: Latches vs lwlock contention