Skip site navigation (1) Skip section navigation (2)

Re: pgsql/src/include (config.h.in)

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: tgl(at)postgresql(dot)org, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql/src/include (config.h.in)
Date: 2000-12-10 20:20:01
Message-ID: 20001210122001.H16205@fw.wintelcom.net (view raw or flat)
Thread:
Lists: pgsql-committers
* Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> [001210 12:03] wrote:
> > > Don't cause --enable-cassert to define COPY_PARSE_PLAN_TREES automatically
> > > anymore.  That won't teach us anything new for the rest of this release
> > > cycle, so it seems better to keep the --assert environment more like the
> > > non-assert environment for beta.
> > > I'm going to leave CLOBBER_FREED_MEMORY and MEMORY_CONTEXT_CHECKING
> > > turned on by --enable-cassert for now, however.
> > 
> > Urk, this looks pretty expensive, is there any flags available that
> > will enable the assertion checking without expensive memory zeroing
> > (or 0xdeadbeef'ing) free'd memory?
> > 
> > Is running enable-cassert on my production boxes going to cause
> > a lot of overhead?
> > 
> 
> Assert adds about 7%, as I remember.

The code could really use a bit of cleanup, a lot of things that
seem like they "shouldn't" happen, just print a message via elog
or something then continue on apparently trashing data.

For instance, the other day I started getting these when trying to
commit a transaction:

  NOTICE:  InvalidateSharedInvalid: cache state reset

Isn't that pretty fatal?  Shouldn't cassert make the database core
at that point?  It's indicative of corruption right?

Should I submit a patch for this case?

Sorry, I'm just a bit upset after thinking everything was running
fine for a couple of hours only to notice that we had a backlog
that took almost two hours to process after restarting postgresql
and vacuuming the table.

Another gripe I have is that, I've just been informed that vacuum
can't always/really fix indicies.  This isn't good, manually dropping
and recreating my indicies every time postgresql died would take
at least half an hour to an hour by hand.  Postgresql has been a
lot more stable for us since 7.0.3 but we had yet another crash
where we needed to "fsck" the database because of corruption
concerns.

Isn't there some startup script that will do this automagically
before bringing the database up in "multiuser mode"?

If someone could give an abstract on how to do this I'm sure
I could write a script to do it.

The combination of adding the appropriate casserts and automatic
safe restart would really make my day.

thanks,
-- 
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]
"I have the heart of a child; I keep it in a jar on my desk."

In response to

Responses

pgsql-committers by date

Next:From: Bruce MomjianDate: 2000-12-10 20:24:04
Subject: Re: pgsql/src/interfaces/libpq (fe-connect.c)
Previous:From: Bruce MomjianDate: 2000-12-10 20:03:01
Subject: Re: pgsql/src/include (config.h.in)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group