Re: ATTACH/DETACH PARTITION CONCURRENTLY - Mailing list pgsql-hackers

From Robert Haas
Subject Re: ATTACH/DETACH PARTITION CONCURRENTLY
Date
Msg-id CA+TgmobuL6h+SVz_XwJAGinnOXDbedKsBNbSGnij_VRK9+w=bw@mail.gmail.com
Whole thread Raw
In response to Re: ATTACH/DETACH PARTITION CONCURRENTLY  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: ATTACH/DETACH PARTITION CONCURRENTLY  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
On Sat, Feb 2, 2019 at 7:19 PM David Rowley
<david.rowley@2ndquadrant.com> wrote:
> 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().

Thanks for the tip.  I see that code, but I'm not sure that I
understand why it matters here.  First, if I'm not mistaken, what's
being returned by ExecFindMatchingSubPlans is a BitmapSet of subplan
indexes, not anything that returns to a PartitionDesc directly.  And
second, even if it did, it looks like the computation is done
separately in every backend and not shared among backends, so even if
it were directly referring to PartitionDesc indexes, it still won't be
assuming that they're the same in every backend.  Can you further
explain your thinking?

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


pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: Pluggable Storage - Andres's take
Next
From: Thomas Munro
Date:
Subject: Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()?