Re: LOCK_DEBUG is busted - Mailing list pgsql-hackers

From Tom Lane
Subject Re: LOCK_DEBUG is busted
Date
Msg-id 17334.1320962662@sss.pgh.pa.us
Whole thread Raw
In response to LOCK_DEBUG is busted  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: LOCK_DEBUG is busted
Re: LOCK_DEBUG is busted
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> It's possible to compile the source tree with LOCK_DEBUG defined, but
> the resulting postgres promptly dumps core, due to the fact that
> user_lockmethod doesn't supply any value for trace_flag; thus, the
> first LockReleaseAll(USER_LOCKMETHOD) dereferences a NULL pointer.
> This is the result of the following commit:

> commit 0180bd6180511875db046bf8ddcaa633a2952dfd

+1 for just reverting that commit.  I'm not sure how much use the
LOCK_DEBUG infrastructure has in exactly its current form, but I can
certainly imagine wanting to use it or some variant of it to debug
tough problems.  If it's gone entirely, people would have to reinvent
most of it for that type of debugging.  On the other side of the coin,
I don't have a clear enough use-case for it to want to spend time
right now on redesigning it, nor a clear idea of exactly what changes
might make it more useful.  So I think we should just revert and
not spend additional effort now.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parsing output of EXPLAIN command in PostgreSQL
Next
From: Bruce Momjian
Date:
Subject: Re: LOCK_DEBUG is busted