On Thu, Nov 10, 2011 at 5:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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.
I don't feel like it accomplishes much of anything that can't be trivially accomplished by throwing in a couple of ad-hoc elog() calls wherever you happen to want them. I experimented with this when developing the fastlock patches and found it didn't tell me what I wanted to know, so just stuck in debugging code in the places that were relevant to my patch's then-current problems. Once those bugs were fixed, I took the debugging code back out. I think the author of this code did pretty much the same thing, but then developed the pretension that the particular places he stuck the elog() calls in would be generally relevant, which I don't believe to be the case. Or maybe they were relevant at one time, but this code has been with us for an awfully long time, and I think it's considerably outlived its usefulness. What I think it's mostly doing at this point is making it more difficult to make further changes - you do whatever you want to do, and then you have to go figure out what to do about the crazy LOCK_DEBUG stuff that no one uses. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
