| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com> |
| Cc: | 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 08:10:18 |
| Message-ID: | 20190513081018.GC2273@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. TransactionLogFetch()
treats bootstrap and frozen XIDs as always committed, so from this
perspective it is not wrong either to complain that this transaction
has already been committed when attempting to abort it. Not sure
what's a more user-friendly behavior in this case though.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2019-05-13 09:14:48 | Re: PostgreSQL 12: Feature Highlights |
| Previous Message | Masahiko Sawada | 2019-05-13 08:01:16 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |