Horton

Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Pavan Deolasee <pavan.deolasee@gmail.com>, amul sul <sulamul@gmail.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-04-05T05:10:06Z
Lists: pgsql-hackers 
On Wednesday, April 4, 2018, Amit Kapila <amit.kapila16@gmail.com> wrote:

> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund <andres@anarazel.de> wrote:
> >
>
> > Questions:
> >
> > - I'm not perfectly happy with
> >   "tuple to be locked was already moved to another partition due to
> concurrent update"
> >   as the error message. If somebody has a better suggestions.
> >
>
> I don't have any better suggestion, but I have noticed a small
> inconsistency in the message.  In case of delete, the message is
> "tuple to be updated was ...". I think here it should be "tuple to be
> deleted was ..."
>

The whole "moved to another partition" explains why and seems better placed
in the errdetail.  The error itself should indicate which attempted action
failed.  And the attempted action for the end user usually isn't the scope
of "locked tuple" - it's the insert or update, the locking is a side effect
(why).

David J.

Commits

  1. Raise error when affecting tuple moved into different partition.

  2. Handle INSERT .. ON CONFLICT with partitioned tables

  3. Change the way we mark tuples as frozen.