Horton

Re: ATTACH/DETACH PARTITION CONCURRENTLY

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Robert Haas <robertmhaas@gmail.com>, 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-16T04:00:23Z
Lists: pgsql-hackers 
On Fri, Nov 16, 2018 at 10:57:57AM +0900, Amit Langote wrote:
> Maybe partition_bounds_create() should've had a MemoryContext argument to
> pass it the context we want it to create the PartitionBoundInfo in.  That
> way, we can simply pass rd_pdcxt to it and avoid making a copy.  As is,
> we're now allocating  two copies of PartitionBoundInfo, one in the
> CurrentMemoryContext and another in rd_pdcxt, whereas the previous code
> would only allocate the latter.  Maybe we should fix it as being a regression.

Not sure about what you mean by regression here, but passing the memory
context as an argument has sense as you can remove the extra partition
bound copy, as it has sense to use an array instead of a list for
performance, which may matter if many partitions are handled when
building the cache.  So cleaning up both things at the same time would
be nice.
--
Michael

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.