Re: Frontend error logging style

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Frontend error logging style
Дата
Msg-id c1d2b11d-d7e2-aafc-4bab-bb41b5f3b5ff@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Frontend error logging style  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Frontend error logging style  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 08.04.22 22:26, Tom Lane wrote:
> I wrote:
>> One other loose end is bothering me: I stuck with logging.h's
>> original choice to put "if (likely())" or "if (unlikely())"
>> conditionals into the macros, but I rather suspect that that's
>> just a waste.  I think we should put a centralized level check
>> into logging.c, and get rid of at least the "if (likely())"
>> checks, because those are going to succeed approximately 100.0%
>> of the time.  Maybe there's an argument for keeping the unlikely()
>> ones.
> 
> Concretely, something like the attached.  As a simple check,
> I looked at the compiled size of pg_dump.  It went from
> 
>    text    data     bss     dec     hex filename
>   380298    4008    1384  385690   5e29a /home/postgres/testversion/bin/pg_dump
> 
> to
> 
>     text    data     bss     dec     hex filename
>   374954    4008    1384  380346   5cdba src/bin/pg_dump/pg_dump
> 
> for a savings of about 5K or 1.5%.  Not a huge amount, but
> not nothing either, especially considering that the existing
> coding isn't buying us anything.

Yeah, that seems ok to change.  The previous coding style is more useful 
if you have a lot of debug messages in a hot code path, but that usually 
doesn't apply to where this is used.



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Allow time delayed standbys and recovery
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Fixes for compression options of pg_receivewal and refactoring of backup_compression.{c,h}