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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, amul sul <sulamul(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
Date: 2018-04-05 05:10:06
Message-ID: CAKFQuwa2DwGhn=HdaQjyBtRV8yHbiRUoOwLdoiA823_y1=JU4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, April 4, 2018, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Thu, Apr 5, 2018 at 7:14 AM, Andres Freund <andres(at)anarazel(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2018-04-05 05:40:29 Re: [HACKERS] GUC for cleanup indexes threshold.
Previous Message TipTop Labs 2018-04-05 05:04:40 Re: BUG #14999: pg_rewind corrupts control file global/pg_control