Re: ATTACH/DETACH PARTITION CONCURRENTLY
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-11-06T18:54:35Z
Lists: pgsql-hackers
On Tue, 6 Nov 2018 at 10:10, Robert Haas <robertmhaas@gmail.com> wrote: > With this > approach, already-running queries won't take into account the fact > that new partitions have been added, but that seems at least tolerable > and perhaps desirable. > Desirable, imho. No data added after a query starts would be visible. > If the > COPY isn't trying to send any tuples to the now-detached partition, > then it's fine, but if it is, then I have trouble seeing any behavior > other than an error as sane, unless perhaps a new partition has been > attached or created for that part of the key space. > Error in the COPY or in the DDL? COPY preferred. Somebody with insert rights shouldn't be able to prevent a table-owner level action. People normally drop partitions to save space, so it could be annoying if that was interrupted. Supporting parallel query shouldn't make other cases more difficult from a behavioral perspective just to avoid the ERROR. The ERROR sounds annoying, but not sure how annoying avoiding it would be. -- Simon Riggs http://www.2ndQuadrant.com/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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