Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags - Mailing list pgsql-hackers

From Greg Stark
Subject Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags
Date
Msg-id 8764rbjlxu.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: slru.c race condition (was Re: TRAP: FailedAssertion("!((itemid)->lp_flags  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> writes:

> Greg Stark <gsstark@mit.edu> writes:
> > I happen to think that except for the rare assertion that has major
> > performance impact all the assertions should be on in production builds. The
> > goal of assertions is to catch corruption quickly and that's something that's
> > just as important in production as it is in debugging.
> 
> You seem not to have read the documentation:

Sure I have, I just disagree.

> 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.

-- 
greg



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Reducing the overhead of NUMERIC data
Next
From: Mike Rylander
Date:
Subject: Re: Reducing the overhead of NUMERIC data