Re: PANIC :Call AbortTransaction when transaction id is no normal
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kuntal Ghosh <kuntalghosh.2007@gmail.com>, Thunder <thunder1@126.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-05-13T18:15:10Z
Lists: pgsql-hackers
Attachments
- fix-bootstrap-signal-handling.patch (text/x-diff) patch
I wrote: > If we do anything at all about this, my thought would just be to change > bootstrap_signals() so that it points all the signal handlers at > quickdie(), or maybe something equivalent to quickdie() but printing > a more apropos message, or even just set them all to SIGDFL since that > means process termination for all of these. die() isn't really the right > thing, precisely because it thinks it can trigger transaction abort, > which makes no sense in bootstrap mode. After further thought I like the SIG_DFL answer, as per attached proposed patch. With this, you get SIGINT behavior like this if you manage to catch it in bootstrap mode (which is not that easy these days): selecting default max_connections ... 100 selecting default shared_buffers ... 128MB selecting default timezone ... America/New_York creating configuration files ... ok running bootstrap script ... ^Cchild process was terminated by signal 2: Interrupt initdb: removing data directory "/home/postgres/testversion/data" That seems perfectly fine from here. > But ... that code's been like that for decades and nobody's complained > before. Why are we worried about bootstrap's response to signals at all? I'm still wondering why the OP cares. Still, the PANIC message that you get right now is potentially confusing. regards, tom lane
Commits
-
In bootstrap mode, use default signal handling for SIGINT etc.
- fb489e4b3195 12.0 landed