Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Pavan Deolasee <pavan.deolasee@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, amul sul <sulamul@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-04-05T19:34:54Z
Lists: pgsql-hackers
Pavan Deolasee wrote: > On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund <andres@anarazel.de> wrote: > + /* > + * As long as we don't support an UPDATE of INSERT ON CONFLICT for > + * a partitioned table we shouldn't reach to a case where tuple to > + * be lock is moved to another partition due to concurrent update > + * of the partition key. > + */ > + Assert(!ItemPointerIndicatesMovedPartitions(&hufd.ctid)); > + > > This is no longer true; at least not entirely. We still don't support ON > CONFLICT DO UPDATE to move a row to a different partition, but otherwise it > works now. See 555ee77a9668e3f1b03307055b5027e13bf1a715. Right. So I think the assert() should remain, but the comment should say "As long as we don't update moving a tuple to a different partition during INSERT ON CONFLICT DO UPDATE on a partitioned table, ..." FWIW I think the code flow is easier to read with the renamed macros. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Raise error when affecting tuple moved into different partition.
- f16241bef7cc 11.0 landed
-
Handle INSERT .. ON CONFLICT with partitioned tables
- 555ee77a9668 11.0 cited
-
Change the way we mark tuples as frozen.
- 37484ad2aace 9.4.0 cited