Re: Frontend error logging style

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-04-08T20:26:49Z
Lists: pgsql-hackers

Attachments

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.

			regards, tom lane

Commits

  1. logging: Also add the command prefix to detail and hint messages

  2. Remove not-very-useful early checks of __pg_log_level in logging.h.

  3. Improve frontend error logging style.

  4. Apply PGDLLIMPORT markings broadly.