Re: [PATCHES] mcxt.c

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: [PATCHES] mcxt.c
Дата
Msg-id 3F5DD84B.3090005@dunslane.net
обсуждение исходный текст
Ответ на Re: [PATCHES] mcxt.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
The particular assertion that was proposed doesn't strike me as terribly 
useful - It should be checked at the point of call rather than inside 
pstrdup, I should have thought.

Of course, that would make for lots of code bloat ... cases like this 
are when gdb is your friend.

cheers

andrew

Tom Lane wrote:

>Greg Stark <gsstark@mit.edu> writes:
>  
>
>>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?
>>    
>>
>
>We generally don't recommend enabling assertions in production
>installations, because it's not clear that there is any net gain in
>stability from doing so.  Per the manual:
>
>     --enable-cassert
>
>         Enables assertion checks in the server, which test for many
>         "can't happen" conditions. This is invaluable for code
>         development purposes, but the tests slow things down a
>         little. Also, having the tests turned on won't necessarily
>         enhance the stability of your server! The assertion checks are
>         not categorized for severity, and so what might be a relatively
>         harmless bug will still lead to server restarts if it triggers
>         an assertion failure.  Currently, this option is not
>         recommended for production use, but you should have it on for
>         development work or when running a beta version.
>
>Obviously this does not apply to cases where the assert is testing
>for something that will cause a core dump anyway, like an improperly
>NULL pointer.  But there are many, many asserts for things that are
>probably not serious bugs (at worst they might deserve a FATAL exit,
>rather than a system-wide PANIC).
>
>Peter E. has speculated about improving the Assert facility to allow
>categorization along this line, but I dunno when it will happen.
>
>As far as your original question goes, I find that
>MEMORY_CONTEXT_CHECKING and CLOBBER_FREED_MEMORY are quite expensive,
>and presently --enable-cassert turns these on.  But of course we could
>decouple that if we were going to encourage people to run with asserts
>enabled in production.  I don't think asserts are hugely expensive
>otherwise (though that might change if we sprinkle them as liberally
>as Gaetano's proposal implies...)
>
>            regards, tom lane
>
>  
>



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: Re: Maximum table size
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Maximum table size