Horton

Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: r.zharkov@postgrespro.ru, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org
Date: 2019-04-02T17:35:54Z
Lists: pgsql-bugs 
Hi,

On 2019-04-02 13:30:56 -0400, Tom Lane wrote:
> But it's hardly plausible that that runs post-commit.

Yea, one surely would hope that that's not happening. I suspect it's
possible it's running pre-commit and somehow the failure handling is
screwed up leading to the 'already committed' error.


> So now I'm thinking that what we really need to know is why a
> TM_Invisible result was returned.  That's going to be a bit harder ...

Yea. I re-skimmed through the code and can't immediately see anything
wrong - not that such subtle issues would necessarily be noticed without
more information.

I wonder, is there a chance that you're using an extension with xact
hooks, or a modified version of postgres?  Could you show us the exact
schema used, and the config?

Greetings,

Andres Freund

Commits

  1. Fix GetNewTransactionId()'s interaction with xidVacLimit.

  2. Fix example in comment.

  3. Fix EvalPlanQualStart to handle partitioned result rels correctly.

  4. Fix a number of issues around modifying a previously updated row.

  5. Use FullTransactionId for the transaction stack.

  6. Add basic infrastructure for 64 bit transaction IDs.

  7. tableam: Add tuple_{insert, delete, update, lock} and use.

  8. Throw error if expiring tuple is again updated or deleted.