From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: more isolation tests for update tuple routing |
Date: | 2019-04-10 00:34:43 |
Message-ID: | 8035e576-0b15-5fa4-6244-1f29da573327@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019/04/10 0:45, Tom Lane wrote:
> Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro HORIGUCHI | 2019-04-10 00:39:29 | Re: shared-memory based stats collector |
Previous Message | Alvaro Herrera | 2019-04-09 23:05:27 | Re: pg_dump is broken for partition tablespaces |