Re: Frontend error logging style
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Michael Paquier <michael@paquier.xyz>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-02-23T16:47:20Z
Lists: pgsql-hackers
Hi, On 2022-02-23 10:30:02 -0500, Tom Lane wrote: > So I now propose modifying yesterday's patch thus: > > * Reinstantiate the PG_LOG_FATAL enum value, add support macros > pg_log_fatal, pg_log_fatal_hint, pg_log_fatal_detail. > > * Define pg_fatal as pg_log_fatal + exit(1). (This would essentially > move pg_rewind's definition into logging.h. pg_upgrade will > define it slightly differently, but the semantics end up the same.) > > * Adjust call sites to match. +1 > I do like this idea because it would not break any existing code > that expects pg_log_fatal to return. There is likely to be some > of that in outstanding patches, and this approach would merely > render it less-than-idiomatic rather than outright broken. > > Updating the patch is going to be a bit tedious, so I'm not > going to do it without buy-in that this solution would be > okay to commit. Any objections? +1 Greetings, Andres Freund
Commits
-
logging: Also add the command prefix to detail and hint messages
- a8cca6026e99 15.0 landed
-
Remove not-very-useful early checks of __pg_log_level in logging.h.
- 2c9381840fe2 15.0 landed
-
Improve frontend error logging style.
- 9a374b77fb53 15.0 landed
-
Apply PGDLLIMPORT markings broadly.
- 8ec569479fc2 15.0 cited