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
-
Fix GetNewTransactionId()'s interaction with xidVacLimit.
- f7feb020c3d8 12.0 landed
-
Fix example in comment.
- 16954e22e2a8 12.0 cited
-
Fix EvalPlanQualStart to handle partitioned result rels correctly.
- 1b5bbe4bcc91 10.8 landed
- b291488da513 11.3 landed
- a8cb8f124679 12.0 landed
-
Fix a number of issues around modifying a previously updated row.
- 41f5e04aec6c 12.0 landed
-
Use FullTransactionId for the transaction stack.
- ad308058cc86 12.0 cited
-
Add basic infrastructure for 64 bit transaction IDs.
- 2fc7af5e9660 12.0 cited
-
tableam: Add tuple_{insert, delete, update, lock} and use.
- 5db6df0c0117 12.0 cited
-
Throw error if expiring tuple is again updated or deleted.
- 6868ed7491b7 9.3.0 cited