From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PANIC serves too many masters |
Date: | 2023-11-20 22:55:32 |
Message-ID: | 1380320.1700520932@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> Is the error level the right way to express what we want to happen? It
> seems like what we really want is to decide on the behavior, i.e.
> restart or not, and generate core or not. That could be done a
> different way, like:
> ereport(PANIC,
> (errmsg("could not locate a valid checkpoint record"),
> errabort(false),errrestart(false)));
Yeah, I was wondering about that too. It feels to me that
PANIC_EXIT is an error level (even more severe than PANIC).
But maybe "no core dump please" should be conveyed separately,
since it's just a minor adjustment that doesn't fundamentally
change what happens. It's plausible that you'd want a core,
or not want one, for different cases that all seem to require
PANIC_EXIT.
(Need a better name than PANIC_EXIT. OMIGOD?)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-11-20 23:35:18 | Re: PANIC serves too many masters |
Previous Message | Nathan Bossart | 2023-11-20 22:52:22 | Re: Hide exposed impl detail of wchar.c |