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

On Thu, Apr 5, 2018 at 10:40 AM, David G. Johnston
<david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> 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).
>

I don't think locking is just a side effect, it will be used when the
user tries to lock tuple via "Select .. For Key Share"

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com