Re: BUG #15727: PANIC: cannot abort transaction 295144144, it wasalready committed
От | Amit Langote |
---|---|
Тема | Re: BUG #15727: PANIC: cannot abort transaction 295144144, it wasalready committed |
Дата | |
Msg-id | 45149dd9-3165-4a87-576f-433e193236f6@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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
В списке pgsql-bugs по дате отправления: