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

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: r.zharkov@postgrespro.ru, Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, pgsql-bugs@lists.postgresql.org
Date: 2019-04-09T04:55:22Z
Lists: pgsql-bugs
On 2019/04/09 1:31, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>> On 2019/04/08 16:21, Amit Langote wrote:
>>> Now that Andres has taken care of the other issues [1], maybe this one's
>>> good to go?  The isolation test part needed to be rebased over Andres'
>>> commit, which I've done in the attached updated patch.
> 
>> The patch I attached in the previous email doesn't apply as-is to
>> back-branches due to rebasing.  I've attached another patch here, which
>> applies to both PG 11 and 10 branches.
> 
> Agreed we can push this now, and done.

Thank you.

> It struck me just as I was pushing it that this test doesn't exercise
> EPQ with any of the interesting cases for partition routing (ie where
> the update causes a move to a different partition).  It would likely
> be a good idea to have test coverage for all of these scenarios:
> 
> * EPQ where the initial update would involve a partition change,
> and that's still true after reapplying the update to the
> concurrently-updated tuple version;
> 
> * EPQ where the initial update would *not* require a partition change,
> but we need one after reapplying the update to the
> concurrently-updated tuple version;
> 
> * EPQ where the initial update would involve a partition change,
> but that's no longer true after reapplying the update to the
> concurrently-updated tuple version.
> 
> You could probably build cases exercising the latter two scenarios
> by doing updates in which the partition key column is set from
> some other column that's modified by the concurrent update.
> 
> 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?

This seems to be documented in the Notes section of UPDATE's page [1].

> None of this is related to bug #15727, though, so I suggest
> starting a new thread with a proposed test patch.

OK, I will post something to -hackers, also considering the tip from Andres.

Thanks,
Amit

[1] https://www.postgresql.org/docs/devel/sql-update.html




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.