Re: pgsql/src/include (config.h.in)
От | Alfred Perlstein |
---|---|
Тема | Re: pgsql/src/include (config.h.in) |
Дата | |
Msg-id | 20001210122001.H16205@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re: pgsql/src/include (config.h.in) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: pgsql/src/include (config.h.in)
|
Список | pgsql-committers |
* 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."
В списке pgsql-committers по дате отправления: