From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Sergei Kornilov <sk(at)zsrv(dot)org>, Amit Langote <langote_amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: ATTACH/DETACH PARTITION CONCURRENTLY |
Date: | 2019-02-04 03:45:25 |
Message-ID: | CA+TgmobuL6h+SVz_XwJAGinnOXDbedKsBNbSGnij_VRK9+w=bw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Feb 2, 2019 at 7:19 PM David Rowley
<david(dot)rowley(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-02-04 03:48:04 | Re: Why are we PageInit'ing buffers in RelationAddExtraBlocks()? |
Previous Message | Haribabu Kommi | 2019-02-04 03:31:59 | Re: Pluggable Storage - Andres's take |