Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>, amul sul <sulamul@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Stephen Frost <sfrost@snowman.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-03-08T17:07:31Z
Lists: pgsql-hackers
On Thu, Mar 8, 2018 at 12:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> Therefore, the only options are (1) ignore the problem, and let a >> cross-partition update look entirely like a delete+insert, (2) try to >> throw some error in the case where this introduces user-visible >> anomalies that wouldn't be visible otherwise, or (3) revert update >> tuple routing entirely. I voted for (1), but the consensus was (2). > > FWIW, I would also vote for (1), especially if the only way to do (2) > is stuff as outright scary as this. I would far rather have (3) than > this, because IMO, what we are looking at right now is going to make > the fallout from multixacts look like a pleasant day at the beach. Whoa. Well, that would clearly be bad, but I don't understand why you find this so scary. Can you explain further? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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