| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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-02 19:04:09 |
| Message-ID: | 7534.1130958249@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
"Jim C. Nasby" <jnasby(at)pervasive(dot)com> writes:
> BTW, that's a reversal from what I was originally arguing for, which was
> due to the performance penalty associated with --enable-cassert. My
> client is now running with Tom's suggestion of commenting out
> CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING and performance is
> good. It appears to be as good as it was with asserts disabled.
Interesting. I've always wondered whether the "debug_assertions" GUC
variable is worth the electrons it's printed on. If you are running
with asserts active, that variable actually slows things down, by
requiring an additional bool test for every Assert. I suppose the
motivation was to allow the same compiled executable to be used for both
assert-enabled and assert-disabled runs, but how many people really need
that capability?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-11-02 19:07:14 | Re: 8.1RC1 fails to build on OS X (10.4) |
| Previous Message | Jim C. Nasby | 2005-11-02 18:57:59 | Re: 8.1RC1 fails to build on OS X (10.4) |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2005-11-02 19:36:19 | Re: [HACKERS] Reducing the overhead of NUMERIC data |
| Previous Message | Jim C. Nasby | 2005-11-02 18:53:07 | Re: Reducing the overhead of NUMERIC data |