Re: old_snapshot_threshold bottleneck on replica

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: old_snapshot_threshold bottleneck on replica
Дата
Msg-id CA+TgmoYOZOU0gyJKLdjudxiEjXEgtvNpeLqoivv6bjVJJHRrFg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: old_snapshot_threshold bottleneck on replica  (Maxim Orlov <orlovmg@gmail.com>)
Ответы Re: old_snapshot_threshold bottleneck on replica
Список pgsql-hackers
On Fri, Jan 27, 2023 at 9:30 AM Maxim Orlov <orlovmg@gmail.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



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: run pgindent on a regular basis / scripted manner
Следующее
От: Dmitry Dolgov
Дата:
Сообщение: Re: Lazy JIT IR code generation to increase JIT speed with partitions