Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags
Дата
Msg-id 22539.1131034302@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags  ("Jim C. Nasby" <jnasby@pervasive.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> May I propose to make Assert() yield only WARNINGs,

That is a horrid idea --- for one thing, it means that Asserts inside
the elog machinery itself would be instant infinite recursion, and even
elsewhere you'd have to think a bit about whether it's ok to call the
elog machinery.  Plus, once you *have* detected an assertion failure,
allowing the code to keep running is just silly.

Either they dump core or they're disabled, there is no third option.

I do think it would be reasonable to fix things so that
MEMORY_CONTEXT_CHECKING could be turned on and off at runtime.

Perhaps rather than an all-or-nothing debug_assertions GUC variable,
what we want is something that turns on or off "expensive" assertion
checks at runtime.  This could include MEMORY_CONTEXT_CHECKING and
anything else where the actual checking of the condition is nontrivial.
(For instance, there is code in list.c that grovels over the whole
list for a consistency check --- that is "expensive".  There is some
code in the bufmgr that scans through all the buffers --- ditto.)
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Wong
Дата:
Сообщение: Re: Spinlocks, yet again: analysis and proposed patches
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Reducing the overhead of NUMERIC data