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

  1. Test some more cases with partitioned tables in EvalPlanQual.