| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: more isolation tests for update tuple routing |
| Date: | 2019-04-09 15:45:20 |
| Message-ID: | [email protected] |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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!
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konstantin Knizhnik | 2019-04-09 15:45:26 | Re: Zedstore - compressed in-core columnar storage |
| Previous Message | Bruce Momjian | 2019-04-09 15:36:24 | Re: [PATCH v20] GSSAPI encryption support |