Обсуждение: pgsql/src/include (config.h.in)
Date: Saturday, December 2, 2000 @ 13:16:40
Author: tgl
Update of /home/projects/pgsql/cvsroot/pgsql/src/include
from hub.org:/home/projects/pgsql/tmp/cvs-serv49789
Modified Files:
config.h.in
----------------------------- Log Message -----------------------------
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.
* tgl@postgresql.org <tgl@postgresql.org> [001203 21:16] wrote: > Date: Saturday, December 2, 2000 @ 13:16:40 > Author: tgl > > Update of /home/projects/pgsql/cvsroot/pgsql/src/include > from hub.org:/home/projects/pgsql/tmp/cvs-serv49789 > > Modified Files: > config.h.in > > ----------------------------- Log Message ----------------------------- > > 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? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein <bright@wintelcom.net> writes:
>> 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?
You can twiddle the declarations in config.h (or config.h.in).
> Is running enable-cassert on my production boxes going to cause
> a lot of overhead?
While I haven't tried hard to measure it, the profiles that I've done
don't show it as a huge cost.
In any case, you're not planning to run beta code as production,
are you?
regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [001204 08:00] wrote: > Alfred Perlstein <bright@wintelcom.net> writes: > >> 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? > > You can twiddle the declarations in config.h (or config.h.in). > > > Is running enable-cassert on my production boxes going to cause > > a lot of overhead? > > While I haven't tried hard to measure it, the profiles that I've done > don't show it as a huge cost. > > In any case, you're not planning to run beta code as production, > are you? Nope, I'm using 7.0.3, but cassert and debug options have helped us a lot in the past when tracking down bugs. :) It would be helpful to have a extra sanity checking option that doesn't do things like clear large blocks of memory. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
> > 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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
* Bruce Momjian <pgman@candle.pha.pa.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@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein <bright@wintelcom.net> writes:
> 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?
No, no, and no.
> Should I submit a patch for this case?
Only if you want to reduce it to a DEBUG notice.
regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [001210 14:26] wrote: > Alfred Perlstein <bright@wintelcom.net> writes: > > 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? > > No, no, and no. > > > Should I submit a patch for this case? > > Only if you want to reduce it to a DEBUG notice. That doesn't seem to make much sense, after I started getting these notices all updates to a particular table would say that then abort my transaction. Perhaps this is the result of a bug in the MMNB/VLAZY stuff from Vadim, but it sure was indicative of something gone horribly wrong, at least for us. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Alfred Perlstein <bright@wintelcom.net> writes:
> That doesn't seem to make much sense, after I started getting
> these notices all updates to a particular table would say
> that then abort my transaction.
The notice itself certainly isn't causing an abort. Let's see
more details.
regards, tom lane