Horton

Re: Frontend error logging style

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

View thread View on postgr.es
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-11T15:22:40Z
Lists: pgsql-hackers 
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 08.04.22 22:26, Tom Lane wrote:
>>> 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.

> 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.

The patch I presented keeps the unlikely() checks in the debug-level
macros.  Do you think we should drop those too?  I figured that avoiding
evaluating the arguments would be worth something.

			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.