On 2019/04/10 0:45, Tom Lane wrote:
> Amit Langote 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: tup
Amit Langote 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 anoth
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