From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] mcxt.c |
Date: | 2003-09-08 21:47:37 |
Message-ID: | 87brtv54w6.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Neil Conway <neilc(at)samurai(dot)com> writes:
> I think the percentage of deployments that enable assertions (which
> causes a runtime performance hit) but NOT debugging info (which does
> not) is pretty small.
How big a penalty is it? If it's small, or if it could be made small by making
a few assertions require an extra extra-assertions option, then perhaps it
would make more sense to ship with it enabled?
I know the number of times I received ORA-600 (oracle's way of spelling
"assertion failed") I sure wouldn't have wanted the database to continue
processing based on invalid data.
> ISTM that checking for non-NULL pointers is pretty pointless: just
> because a pointer happens to be non-NULL doesn't mean it is any more
> valid, and dereferencing a NULL pointer is easy enough to track down in
> any case.
That would depend a lot on the scenario. Often code doesn't crash right at
that point but stores the data causes a crash elsewhere. Or perhaps even
causes corrupted data on disk.
Probably the most useful side-effect of checking for null pointers is that
programmers get in the habit of checking all their arguments...
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-09-08 21:53:12 | Re: FreeBSD/i386 thread test |
Previous Message | Gaetano Mendola | 2003-09-08 21:43:21 | Re: constraint modification on todo list |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-09-08 21:58:09 | Re: ISO 8601 'Time Intervals' of the 'format with time-unit |
Previous Message | Tom Lane | 2003-09-08 21:19:13 | Re: ISO 8601 "Time Intervals" of the "format with time-unit deignators" |