| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | knizhnik <knizhnik(at)garret(dot)ru> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease |
| Date: | 2014-02-14 16:28:28 |
| Message-ID: | 20140214162828.GU4910@awork2.anarazel.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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==NULL but 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | eshkinkot | 2014-02-14 16:31:25 | BUG #9223: plperlu result memory leak |
| Previous Message | knizhnik | 2014-02-14 16:23:32 | Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease |