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