From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Cc: Thunder <thunder1@126.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: PANIC :Call AbortTransaction when transaction id is no normal
Date: Mon, 13 May 2019 14:15:10 -0400
Message-ID: <5787.1557771310@sss.pgh.pa.us> (raw)
In-Reply-To: <15939.1557754652@sss.pgh.pa.us>
References: <3850b11a.5121.16aaf827e4a.Coremail.thunder1@126.com>
<CAGz5QCJKDptF4R0xHzM9YLxbLwZHA9enW9zjOi+vF93HVycVgw@mail.gmail.com>
<20190513081018.GC2273@paquier.xyz>
<15939.1557754652@sss.pgh.pa.us>
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
Attachments:
[text/x-diff] fix-bootstrap-signal-handling.patch (833B, ../5787.1557771310@sss.pgh.pa.us/2-fix-bootstrap-signal-handling.patch)
download | inline diff:diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.cindex d8776e1..825433d 100644--- a/src/backend/bootstrap/bootstrap.c+++ b/src/backend/bootstrap/bootstrap.c@@ -558,11 +558,16 @@ bootstrap_signals(void)
{
Assert(!IsUnderPostmaster);
- /* Set up appropriately for interactive use */- pqsignal(SIGHUP, die);- pqsignal(SIGINT, die);- pqsignal(SIGTERM, die);- pqsignal(SIGQUIT, die);+ /*+ * We don't actually need any non-default signal handling in bootstrap+ * mode; "curl up and die" is a sufficient response for all these cases.+ * But let's just make sure the signals are set that way, since our parent+ * process initdb has them set differently.+ */+ pqsignal(SIGHUP, SIG_DFL);+ pqsignal(SIGINT, SIG_DFL);+ pqsignal(SIGTERM, SIG_DFL);+ pqsignal(SIGQUIT, SIG_DFL);
}
/*
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, michael@paquier.xyz, kuntalghosh.2007@gmail.com, thunder1@126.com, pgsql-hackers@lists.postgresql.org
Subject: Re: PANIC :Call AbortTransaction when transaction id is no normal
In-Reply-To: <5787.1557771310@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox