Re: LOCK_DEBUG is busted

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: LOCK_DEBUG is busted
Date: 2011-11-10 22:04:22
Message-ID: 17334.1320962662@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-11-10 22:05:57 Re: LOCK_DEBUG is busted
Previous Message Tom Lane 2011-11-10 21:59:29 Re: Parsing output of EXPLAIN command in PostgreSQL