Re: ATTACH/DETACH PARTITION CONCURRENTLY
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
Michael Paquier <michael@paquier.xyz>, Sergei Kornilov <sk@zsrv.org>, Amit Langote <langote_amit_f8@lab.ntt.co.jp>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Simon Riggs <simon@2ndquadrant.com>
Date: 2018-12-24T19:19:24Z
Lists: pgsql-hackers
On Fri, Dec 21, 2018 at 6:06 PM David Rowley <david.rowley@2ndquadrant.com> wrote: > > I didn't handle that. If partition pruning relies on nothing changing > > between planning and execution, isn't that broken regardless of any of > > this? It's true that with the simple query protocol we'll hold locks > > continuously from planning into execution, and therefore with the > > current locking regime we couldn't really have a problem. But unless > > I'm confused, with the extended query protocol it's quite possible to > > generate a plan, release locks, and then reacquire locks at execution > > time. Unless we have some guarantee that a new plan will always be > > generated if any DDL has happened in the middle, I think we've got > > trouble, and I don't think that is guaranteed in all cases. > > Today the plan would be invalidated if a partition was ATTACHED or > DETACHED. The newly built plan would get the updated list of > partitions. I think you're right, and that won't be true any more once we lower the lock level, so it has to be handled somehow. The entire plan invalidation mechanism seems to depend fundamentally on AccessExclusiveLock being used everywhere, so this is likely to be an ongoing issue every time we want to reduce a lock level anywhere. I wonder if there is any kind of systematic fix or if we are just going to have to keep inventing ad-hoc solutions. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Allow ATTACH PARTITION with only ShareUpdateExclusiveLock.
- 898e5e3290a7 12.0 landed
-
Change lock acquisition order in expand_inherited_rtentry.
- f4b6341d5fcb 12.0 landed
-
Move code for managing PartitionDescs into a new file, partdesc.c
- 1bb5e7821810 12.0 landed
-
Remove more redundant relation locking during executor startup.
- f2343653f5b2 12.0 cited
-
Add assertions that we hold some relevant lock during relation open.
- b04aeb0a053e 12.0 cited
-
Try to acquire relation locks in RangeVarGetRelid.
- 4240e429d0c2 9.2.0 cited