Re: LogwrtResult contended spinlock
От | Andres Freund |
---|---|
Тема | Re: LogwrtResult contended spinlock |
Дата | |
Msg-id | E494450B-9C6B-4716-9902-976DC7D69490@anarazel.de обсуждение исходный текст |
Ответ на | Re: LogwrtResult contended spinlock (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: LogwrtResult contended spinlock
|
Список | pgsql-hackers |
Hi, On August 31, 2020 11:34:45 AM PDT, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >On 2020-Aug-31, Andres Freund wrote: > >> Hi, >> >> On August 31, 2020 11:21:56 AM PDT, Alvaro Herrera ><alvherre@2ndquadrant.com> wrote: > >> >At first I wanted to make the new LWLock cover only LogwrtResult >> >proper, >> >and leave LogwrtRqst alone. However on doing it, it seemed that >that >> >might change the locking protocol in a nontrivial way. So I decided >to >> >make it cover both and call it a day. We did verify that the patch >> >solves the reported problem, at any rate. >> >> Wouldn't the better fix here be to allow reading of individual >members >> without a lock? E.g. by wrapping each in a 64bit atomic. > >Heh, Simon said the same. It's not clear to me due to the lack of >general availability of 64-bit atomics. If they are spinlock-protected >when emulated, I think that would make the problem worse. > >IIRC Thomas wanted to start relying on atomic 64-bit vars in some >patch, >but I don't remember what it was. All relevant platforms have 64bit atomics. So I don't think there's much point in worrying about the emulated performance.Correctness, sure. Performance, not so much. Andres -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
В списке pgsql-hackers по дате отправления: