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

Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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.

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?

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

regards, tom lane