Re: old_snapshot_threshold bottleneck on replica

From: Maxim Orlov <orlovmg(at)gmail(dot)com>
To: Robert Haas <robertmhaas(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 14:30:11
Message-ID: CACG=ezbs6pHddXtGpdaCm+VT_2BQsu53OVZLjYVPc9ABRAaaQg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 25 Jan 2023 at 16:52, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Jan 25, 2023 at 3:52 AM Maxim Orlov <orlovmg(at)gmail(dot)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 Content-Type Size
v3-0001-Use-atomic-old_snapshot_threshold.patch application/octet-stream 4.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2023-01-27 14:39:16 Re: Latches vs lwlock contention
Previous Message vignesh C 2023-01-27 14:27:10 Re: SQL/JSON revisited