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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key
Дата
Msg-id CAKFQuwa2DwGhn=HdaQjyBtRV8yHbiRUoOwLdoiA823_y1=JU4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key  (Amit Kapila <amit.kapila16@gmail.com>)
Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key  (Andres Freund <andres@anarazel.de>)
Список 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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: [HACKERS] GUC for cleanup indexes threshold.