Обсуждение: more isolation tests for update tuple routing

Continuing the discussion at:
https://www.postgresql.org/message-id/26571.1554741097%40sss.pgh.pa.us

Tom wrote:
> 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.

Per what Andres mentioned in his reply on the original thread [1], in
scenarios 1 and 2 where the 1st session's update causes a row to move,
session 2 produces the following error when trying to update the same row:

ERROR:  tuple to be locked was already moved to another partition due to
concurrent update

Do we want those tests like that (with the error that is) in the
eval-plan-qual isolation suite?

I came up with the attached.

Thanks,
Amit

[1]
https://www.postgresql.org/message-id/20190408164138.izvfg2czwcofg5ev%40alap3.anarazel.de

Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> Per what Andres mentioned in his reply on the original thread [1], in
> scenarios 1 and 2 where the 1st session's update causes a row to move,
> session 2 produces the following error when trying to update the same row:
> ERROR:  tuple to be locked was already moved to another partition due to
> concurrent update

> Do we want those tests like that (with the error that is) in the
> eval-plan-qual isolation suite?

Sure, but I think one such test is enough.

> I came up with the attached.

I changed the last case so it actually did what I had in mind
(initial state of the update would be a partition move, but after
fetching up-to-date tuple it isn't) and pushed it.  Thanks for
doing the legwork!

            regards, tom lane

On 2019/04/10 0:45, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>> Per what Andres mentioned in his reply on the original thread [1], in
>> scenarios 1 and 2 where the 1st session's update causes a row to move,
>> session 2 produces the following error when trying to update the same row:
>> ERROR:  tuple to be locked was already moved to another partition due to
>> concurrent update
> 
>> Do we want those tests like that (with the error that is) in the
>> eval-plan-qual isolation suite?
> 
> Sure, but I think one such test is enough.
> 
>> I came up with the attached.
> 
> I changed the last case so it actually did what I had in mind
> (initial state of the update would be a partition move, but after
> fetching up-to-date tuple it isn't) and pushed it.  Thanks for
> doing the legwork!

Thank you.

Regards,
Amit