Horton

Re: ATTACH/DETACH PARTITION CONCURRENTLY

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: David Rowley <david.rowley@2ndquadrant.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-04T12:54:15Z
Lists: pgsql-hackers 
On Mon, Feb 4, 2019 at 12:02 AM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> If the PartitionDesc from the parallel worker has an extra partition
> than what was there when the plan was built then the partition index
> to subplan index translation will be incorrect as the
> find_matching_subplans_recurse() will call get_matching_partitions()
> using the context with the PartitionDesc containing the additional
> partition. The return value from get_matching_partitions() is fine,
> it's just that the code inside the while ((i =
> bms_next_member(partset, i)) >= 0) loop that will do the wrong thing.
> It could even crash if partset has an index out of bounds of the
> subplan_map or subpart_map arrays.

Is there any chance you've missed the fact that in one of the later
patches in the series I added code to adjust the subplan_map and
subpart_map arrays to compensate for any extra partitions?

-- 
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.