Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "David G. Johnston" <david.g.johnston@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-05T06:08:26Z
Lists: pgsql-hackers
On Thu, Apr 5, 2018 at 10:40 AM, David G. Johnston <david.g.johnston@gmail.com> wrote: > 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). > 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
Commits
-
Raise error when affecting tuple moved into different partition.
- f16241bef7cc 11.0 landed
-
Handle INSERT .. ON CONFLICT with partitioned tables
- 555ee77a9668 11.0 cited
-
Change the way we mark tuples as frozen.
- 37484ad2aace 9.4.0 cited