Re: PANIC :Call AbortTransaction when transaction id is no normal
Kuntal Ghosh <kuntalghosh.2007@gmail.com>
From: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Thunder <thunder1@126.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-05-13T14:13:24Z
Lists: pgsql-hackers
On Mon, May 13, 2019 at 7:07 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael@paquier.xyz> writes: > > On Mon, May 13, 2019 at 01:25:19PM +0530, Kuntal Ghosh wrote: > >> If we fix the issue in this way, we're certainly not going to do all > >> those portal,locks,memory,resource owner cleanups that are done > >> inside AbortTransaction() for a normal transaction ID. But, I'm not > >> sure how relevant those steps are since the database is anyway > >> shutting down. > > > And it is happening in bootstrap, meaning that the data folder is most > > likely toast, and needs to be reinitialized. > > Indeed, initdb is going to remove the data directory if the bootstrap run > crashes. > > 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? > > +1 -- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com
Commits
-
In bootstrap mode, use default signal handling for SIGINT etc.
- fb489e4b3195 12.0 landed