more isolation tests for update tuple routing
Continuing the discussion at:
/messages/by-id/26571.1554741097@sss.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]/messages/by-id/20190408164138.izvfg2czwcofg5ev@alap3.anarazel.de, 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]: /messages/by-id/20190408164138.izvfg2czwcofg5ev@alap3.anarazel.de
/messages/by-id/20190408164138.izvfg2czwcofg5ev@alap3.anarazel.de
Attachments:
parted-update-EPQ-more-isolation-tests-1.patchtext/plain; charset=UTF-8; name=parted-update-EPQ-more-isolation-tests-1.patchDownload+90-2
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 updateDo 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