Re: PANIC :Call AbortTransaction when transaction id is no normal

From: Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Thunder <thunder1(at)126(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PANIC :Call AbortTransaction when transaction id is no normal
Date: 2019-05-13 14:13:24
Message-ID: CAGz5QCJ+VfrmJf6buXgJtUckEpfKCb41j4OsiowhCksh-RLD3A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 13, 2019 at 7:07 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Michael Paquier <michael(at)paquier(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2019-05-13 14:47:49 Re: Passing CopyMultiInsertInfo structure to CopyMultiInsertInfoNextFreeSlot()
Previous Message David Rowley 2019-05-13 13:46:00 Re: Passing CopyMultiInsertInfo structure to CopyMultiInsertInfoNextFreeSlot()