Tom Lane 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 am confused. I thought it was lock_debug referencing user locks that was broken. Does lock_debug need user locks? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
