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
|
Список | 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 по дате отправления: