| From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:01:24 |
| Message-ID: | 20051103160124.GB7138@surnet.cl |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
Jim C. Nasby wrote:
> BTW, is MEMORY_CONTEXT_CHECKING that expensive? It seems like it
> shouldn't be, but I'm only guessing at what exactly it does...
Yes, because not only it checks marker bytes at the end of palloc chunks
and similar stuff, but it also overwrites whole contexts with 0x7f when
they are reset.
May I propose to make Assert() yield only WARNINGs, and take out the
most expensive parts of MEMORY_CONTEXT_CHECKING, when --enable-cassert
is disabled? Enabling it would trigger the current FailedAssertion and
all of MEMORY_CONTEXT_CHECKING. That way we get all bug reports without
the expensive runtime costs for in-production systems.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Wong | 2005-11-03 16:03:48 | Re: Spinlocks, yet again: analysis and proposed patches |
| Previous Message | Tom Lane | 2005-11-03 15:32:03 | Re: Reducing the overhead of NUMERIC data |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-11-03 16:11:42 | Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags |
| Previous Message | Tom Lane | 2005-11-03 15:32:03 | Re: Reducing the overhead of NUMERIC data |