Re: pgsql: Fix race condition in snapshot caching when 2PC is used.
От | Tom Lane |
---|---|
Тема | Re: pgsql: Fix race condition in snapshot caching when 2PC is used. |
Дата | |
Msg-id | 1356510.1597794950@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: Fix race condition in snapshot caching when 2PC is used. (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: pgsql: Fix race condition in snapshot caching when 2PC is used.
|
Список | pgsql-committers |
Andres Freund <andres@anarazel.de> writes: > On 2020-08-18 19:43:24 -0400, Tom Lane wrote: >> Uh, is it really okay to modify that variable with only shared >> ProcArrayLock? > Uh, you're right. I assume it'll fix the buildfarm visible issue > regardless, but we surely don't want to rely on that. Yeah, having a failure show on the buildfarm would take an order of magnitude (at least) tighter timing than what we're seeing now. But I think it could possibly be a problem on big production iron. > I'm inclined to just make ClearTransaction take an exclusive lock - the > rest of the 2PC operations are so heavyweight that I can't imagine > making a difference. When I tested the locking changes in > ProcArrayAdd()/Remove() the more heavyweight locking wasn't at all > visible. I was wondering if it'd be sensible to convert that counter into an atomic variable. That's not real clear, but worth thinking about. regards, tom lane
В списке pgsql-committers по дате отправления: