Re: more isolation tests for update tuple routing
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2019-04-09T15:45:20Z
Lists: pgsql-hackers
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
Commits
-
Test some more cases with partitioned tables in EvalPlanQual.
- a2418f9e2387 12.0 landed