Re: LogwrtResult contended spinlock
От | Andres Freund |
---|---|
Тема | Re: LogwrtResult contended spinlock |
Дата | |
Msg-id | 20200904170545.ko4bwixl3yuu5jxz@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: LogwrtResult contended spinlock (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: LogwrtResult contended spinlock
|
Список | pgsql-hackers |
Hi, On 2020-09-03 14:34:52 -0400, Alvaro Herrera wrote: > Looking at patterns like this > > if (XLogCtl->LogwrtRqst.Write < EndPos) > XLogCtl->LogwrtRqst.Write = EndPos; > > It seems possible to implement with > > do { > XLogRecPtr currwrite; > > currwrite = pg_atomic_read_u64(LogwrtRqst.Write); > if (currwrite > EndPos) > break; // already done by somebody else > if (pg_atomic_compare_exchange_u64(LogwrtRqst.Write, > currwrite, EndPos)) > break; // successfully updated > } while (true); > > This assumes that LogwrtRqst.Write never goes backwards, so it doesn't > seem good material for a general routine. > > This *seems* correct to me, though this is muddy territory to me. Also, > are there better ways to go about this? Hm, I was thinking that we'd first go for reading it without a spinlock, but continuing to write it as we currently do. But yea, I can't see an issue with what you propose here. I personally find do {} while () weird and avoid it when not explicitly useful, but that's extremely minor, obviously. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: