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

  1. Allow ATTACH PARTITION with only ShareUpdateExclusiveLock.

  2. Change lock acquisition order in expand_inherited_rtentry.

  3. Move code for managing PartitionDescs into a new file, partdesc.c

  4. Remove more redundant relation locking during executor startup.

  5. Add assertions that we hold some relevant lock during relation open.

  6. Try to acquire relation locks in RangeVarGetRelid.