Re: [PATCHES] mcxt.c - Mailing list pgsql-hackers

From Greg Stark
Subject Re: [PATCHES] mcxt.c
Date
Msg-id 87brtv54w6.fsf@stark.dyndns.tv
Whole thread Raw
In response to Re: [PATCHES] mcxt.c  (Neil Conway <neilc@samurai.com>)
Responses Re: [PATCHES] mcxt.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Neil Conway <neilc@samurai.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



pgsql-hackers by date:

Previous
From: "Gaetano Mendola"
Date:
Subject: Re: constraint modification on todo list
Next
From: Peter Eisentraut
Date:
Subject: Re: FreeBSD/i386 thread test