From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:48:27 |
Message-ID: | 81a0ae802a2a6ac8ff44ef2138f7a7519a6fab93.camel@j-davis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2023-11-20 at 17:12 -0500, Tom Lane wrote:
> I'd be inclined to keep PANIC with its current meaning, and
> incrementally change call sites where we decide that's not the
> best behavior. I think those will be a minority, maybe a small
> minority. (PANIC_EXIT had darn well better be a small minority.)
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)));
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2023-11-20 22:48:42 | Re: Partial aggregates pushdown |
Previous Message | Tom Lane | 2023-11-20 22:29:03 | Re: PSQL error: total cell count of XXX exceeded |