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  (Bruce Momjian <bruce@momjian.us>)
Re: LOCK_DEBUG is busted  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Parsing output of EXPLAIN command in PostgreSQL
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: LOCK_DEBUG is busted