From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags |
Date: | 2005-11-03 16:11:42 |
Message-ID: | 22539.1131034302@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2005-11-03 16:22:42 | Re: Reducing the overhead of NUMERIC data |
Previous Message | Mark Wong | 2005-11-03 16:03:48 | Re: Spinlocks, yet again: analysis and proposed patches |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2005-11-03 16:22:42 | Re: Reducing the overhead of NUMERIC data |
Previous Message | Alvaro Herrera | 2005-11-03 16:01:24 | Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags |