| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| 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 03:44:25 |
| Message-ID: | 941719.1645587865@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> What about adding a pg_fatal() that's pg_log_fatal() + exit()? That keeps
> pg_log_* stuff "log only", but adds something adjacent enough to hopefully
> reduce future misunderstandings?
I'd be okay with that, except that pg_upgrade already has a pg_fatal
(because it has its *own* logging system, just in case you thought
this wasn't enough of a mess yet). I'm in favor of aligning
pg_upgrade's logging with the rest, but I'd hoped to leave that for
later. Making the names collide would be bad even as a short-term
thing, I fear.
Looks like libpq_pipeline.c has its own pg_fatal, too.
I'm not against choosing some name other than pg_log_fatal, but that
particular suggestion has got conflicts. Got any other ideas?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2022-02-23 03:47:31 | Re: Design of pg_stat_subscription_workers vs pgstats |
| Previous Message | Andres Freund | 2022-02-23 03:11:37 | Re: Frontend error logging style |