Date: Thu, 5 Apr 2018 16:34:54 -0300
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>
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE of
 partition key
Message-ID: <20180405193454.el2bffwijtsa7rbg@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CABOikdOS9+iq+j-ZtKAmXwEtdgXXvJPQxED14nAU5j8F17wTXg@mail.gmail.com>
User-Agent: NeoMutt/20170306-137-4415bd-dirty (1.8.0)
Precedence: bulk

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