Re: old_snapshot_threshold bottleneck on replica

Поиск
Список
Период
Сортировка
От Maxim Orlov
Тема Re: old_snapshot_threshold bottleneck on replica
Дата
Msg-id CACG=ezbs6pHddXtGpdaCm+VT_2BQsu53OVZLjYVPc9ABRAaaQg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: old_snapshot_threshold bottleneck on replica  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: old_snapshot_threshold bottleneck on replica  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Дерево обсуждения

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.
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: vignesh C
Дата:
Сообщение: Re: SQL/JSON revisited
Следующее
От: vignesh C
Дата:
Сообщение: Re: Latches vs lwlock contention