Re: ATTACH/DETACH PARTITION CONCURRENTLY

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Michael Paquier <michael@paquier.xyz>, David Rowley <david.rowley@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Simon Riggs <simon@2ndquadrant.com>
Date: 2018-11-19T17:13:56Z
Lists: pgsql-hackers
On Sun, Nov 18, 2018 at 9:43 PM Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2018/11/17 9:06, Michael Paquier wrote:
> > On Fri, Nov 16, 2018 at 09:38:40AM -0500, Robert Haas wrote:
> >> OK, but it seems to me that your version of my patch rearranges the
> >> code more than necessary.
> >>
> >> How about the attached?
> >
> > What you are proposing here looks good to me.  Thanks!
>
> Me too, now that I see the patch closely.  The errors I'd seen in the
> regression tests were due to uninitialized oids variable which is fixed in
> the later patches, not due to "confused memory context switching" as I'd
> put it [1] and made that the reason for additional changes.

OK.  Rebased again, and committed (although I forgot to include a link
to this discussion - sorry about that).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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.