Hi, (Coming back to this after looking at a bunch of core dumps from disk-full PANICs.)
On Sat, 12 Sept 2026 at 03:10, Jeff Davis <[email protected]> wrote: > > 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))); I gave the core-dump part of this a try. Two WIP patches attached. I first thought of adding PANIC_NO_CORE, but wasn't sure where to put it. Below PANIC, we'd have to adjust checks like elevel >= PANIC. Above PANIC, it could take precedence over an ordinary PANIC during nested error reporting. Neither seemed quite right when all I wanted was to avoid the core dump. Following your suggestion, I kept PANIC and added a flag to ErrorData. The call sites use errnocoredump_on_errno(ENOSPC), which checks the saved errno. For a marked PANIC, errfinish() takes the _exit(2) path instead of calling abort(). There's also a developer GUC to get the abort() behavior back when needed. (may not be needed?) The second patch adds this to selected WAL and pg_control error paths. I haven't changed the restart policy in any of them, patch is just for the core dump behaviour. Would something along these lines make sense? Regards, Ayush
v1-0001-Allow-selected-PANIC-errors-to-skip-core-dumps.patch
Description: Binary data
v1-0002-Avoid-core-dumps-for-WAL-disk-full-failures.patch
Description: Binary data
