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: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, r.zharkov@postgrespro.ru, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org
Date: 2019-04-08T16:41:38Z
Lists: pgsql-bugs 
Hi,

On 2019-04-08 12:31:37 -0400, Tom Lane wrote:
> BTW, what happens if the concurrent update caused a partition change?
> I imagine we would think the original tuple is now dead, since there's
> no way to chase up to the replacement tuple in the other partition,
> and so we'd abandon our update.  Is this documented?

FWIW, you should get an error:
                if (ItemPointerIndicatesMovedPartitions(tid))
                    ereport(ERROR,
                            (errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
                             errmsg("tuple to be locked was already moved to another partition due to concurrent update")));

I think there's tests for the simpler cases. Probably wouldn't hurt to
test that case as another axis for the suite of tests you suggest.

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.