Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
От | Andres Freund |
---|---|
Тема | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease |
Дата | |
Msg-id | 20140214162828.GU4910@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease (knizhnik <knizhnik@garret.ru>) |
Ответы |
Re: Memory ordering issue in LWLockRelease, WakeupWaiters,
WALInsertSlotRelease
|
Список | pgsql-hackers |
On 2014-02-14 20:23:32 +0400, knizhnik wrote: > >>we'll trade correctness for cleanliness if we continue to reset lwWaitLink > >>without protecting against the race. That's a bit of a weird trade-off to make. > > > >It's not just cleanliness, it's being able to actually debug crashes. > > > Frankly speaking I do not understand why elimination of resetting of lwWaitLink was considered to be bad idea. > Resetting this pointer to NULL will not help much to analyze crash dumps, because right now it is possible that lwWaitLink==NULLbut process in waiting for a lock and linked in the list > (if it is the last element of the list). So the fact that lwWaitLink==NULL actually gives not so much useful information. At the moment if you connect to a live pg or a crash dump, investigating the wait links allows you to somewhat sensibly determine which backends are waiting for a lock and whether they are part of a queue. If they aren't reset anymore that will tell you nothing, so you'll need to connect to all pg instances to debug issues. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: