Re: LOCK_DEBUG is busted
От | Tom Lane |
---|---|
Тема | Re: LOCK_DEBUG is busted |
Дата | |
Msg-id | 17334.1320962662@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | LOCK_DEBUG is busted (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: LOCK_DEBUG is busted
Re: LOCK_DEBUG is busted |
Список | 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 по дате отправления: