Horton

Re: ATTACH/DETACH PARTITION CONCURRENTLY

David Rowley <david.rowley@2ndquadrant.com>

View thread View on postgr.es
From: David Rowley <david.rowley@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.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: 2019-02-03T00:18:47Z
Lists: pgsql-hackers 
On Sat, 2 Feb 2019 at 09:31, Robert Haas <robertmhaas@gmail.com> wrote:
> After having written this code, I'm still torn about whether to go
> further with this design.  On the one hand, this is such boilerplate
> code that it's kinda hard to imagine it having too many more bugs; on
> the other hand, as you can see, it's a non-trivial amount of code to
> add without a real clear reason, and I'm not sure we have one, even
> though in the abstract it seems like a better way to go.

I think we do need to ensure that the PartitionDesc matches between
worker and leader. Have a look at choose_next_subplan_for_worker() in
nodeAppend.c. Notice that a call is made to
ExecFindMatchingSubPlans().


-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, 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.