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 по дате отправления: