Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: r.zharkov@postgrespro.ru, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org
Date: 2019-04-02T17:30:56Z
Lists: pgsql-bugs 
Andres Freund <andres@anarazel.de> writes:
> On 2019-04-02 13:13:58 -0400, Tom Lane wrote:
>> FWIW, I see six potential candidates, not two:

> These have an explicit case / separate error for TM_Invisible (= 1 -
> which is the status we're seeing according to the error message)
> though. So afaict they can't be relevant here.

Oh, right, so it has to be from one of the calls in nodeModifyTable.c.
But it's hardly plausible that that runs post-commit.  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 ...

			regards, tom lane

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.