Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
От | Andres Freund |
---|---|
Тема | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease |
Дата | |
Msg-id | 20140214153230.GQ4910@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
|
Список | pgsql-hackers |
On 2014-02-14 10:26:07 -0500, Tom Lane wrote: > Florian Pflug <fgp@phlo.org> writes: > > Another idea for a fix would be to conflate lwWaiting and lwWaitLink into one > > field. We could replace "lwWaiting" by "lwWaitLink != NULL" everywhere it's > > tested, and set lwWaitLink to some special non-NULL value (say 0x1) when we > > enqueue a PGPROC, instead of setting it to NULL and setting lwWaiting to true. > > > We'd then depend on pointer-sized stores being atomic, which I think we depend > > on in other places already. > > I don't believe that's true; neither that we depend on it now, nor that > it would be safe to do so. Yea, we currently rely on 4 byte stores being atomic (most notably for xids), but we don't rely on anything bigger. I am not sure if there are architectures with 64bit pointers that aren't accessed atomically when aligned? Even if, that's certainly nothing that should be introduced when backpatching. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: