On 02/14/2014 08:28 PM, Andres Freund wrote:
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.
Why it is not enough to inspect lwWaiting flag?
In any case, resetting lwWaitLink can be safely done in awakened process:
if (!proc->lwWaiting) {
>>> proc->lwWaitLink = NULL;
break;
}
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
