Re: [PATCHES] mcxt.c
От | Greg Stark |
---|---|
Тема | Re: [PATCHES] mcxt.c |
Дата | |
Msg-id | 87brtv54w6.fsf@stark.dyndns.tv обсуждение исходный текст |
Ответ на | Re: [PATCHES] mcxt.c (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: [PATCHES] mcxt.c
|
Список | 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 по дате отправления: