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