From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Frontend error logging style |
Date: | 2022-02-23 16:47:20 |
Message-ID: | 20220223164720.6x5ezuudcrhiopnz@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2022-02-23 17:20:54 | Re: bailing out in tap tests nearly always a bad idea |
Previous Message | Andres Freund | 2022-02-23 16:40:10 | Re: bailing out in tap tests nearly always a bad idea |