On Wed, Nov 02, 2005 at 07:03:57AM -0500, Greg Stark wrote: > > I would bet that ninety percent of the Asserts in the existing code are on > > conditions that could represent, at worst, corruption of backend-local or > > even transaction-local data structures. Taking down the entire database > > cluster for that is not something that sounds like a stability-enhancing > > tradeoff to me. > > It may be minor corruption or it may be that the reason for the minor > corruption comes from some larger bug. It may also be backend-local or > transaction-local corruption at the time the assert catches it but cause major > damage by the time it actually crashes a non-assert-enabled database.
Agreed. Personally I'd want to know about anything that corrupts my data, no matter what the locality. I would also argue that if people are seeing 'minor' asserts firing in production that there's a bug that needs to be tracked down. IF it comes out that there's some asserts that can be fired even though there's not anything really bad happening, they could always be relegated to a second class of assert that's not normally turned on. 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. So I think it would definately be good to break those options out from --enable-cassert. That makes it viable to run with asserts in production, at least from a performance standpoint. BTW, they're also running with patch2 now. Previously, with asserts turned on and without the patch, they were seeing assert failures on average of 2/day. So hopefully tomorrow we'll have an idea if the patch fixed this or not. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
