Re: more isolation tests for update tuple routing
От | Tom Lane |
---|---|
Тема | Re: more isolation tests for update tuple routing |
Дата | |
Msg-id | 17836.1554824720@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | more isolation tests for update tuple routing (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: more isolation tests for update tuple routing
|
Список | 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
В списке pgsql-hackers по дате отправления: