Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()
Дата
Msg-id CAFjFpRe_GKCHGwbNt6NgwPuwW1qM1Fhuo2y5Mzwv7_99DfuX7A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Thu, Jun 15, 2017 at 4:06 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
>
> Anyway, I tried to implement the refactoring in patch 0002, which is not
> all of the patch 0001 that Jeevan posted.  Please take a look.  I wondered
> if we should emit a NOTICE when an individual leaf partition validation
> can be skipped?

Yes. We emit an INFO for the table being attached. We want to do the
same for the child. Or NOTICE In both the places.

> No point in adding a new test if the answer to that is
> no, I'd think.
>
> Attaching here 0001 which fixes the bug (unchanged from the previous
> version) and 0002 which implements the refactoring (and the feature to
> look at the individual leaf partitions' constraints to see if validation
> can be skipped.)

Comments on 0001 patch.
+     *
+     * We request an exclusive lock on all the partitions, because we may
+     * decide later in this function to scan them to validate the new
+     * partition constraint.
Does that mean that we may not scan the partitions later, in which the stronger
lock we took was not needed. Is that right? Don't we need an exclusive lock to
make sure that the constraints are not changed while we are validating those?
   if (!skip_validate)
May be we should turn this into "else" condition of the "if" just above.

+        /*
+         * We already collected the list of partitions, including the table
+         * named in the command itself, which should appear at the head of the
+         * list.
+         */
+        Assert(list_length(attachRel_children) >= 1 &&
+            linitial_oid(attachRel_children) == RelationGetRelid(attachRel));
Probably the Assert should be moved next to find_all_inheritors(). But I don't
see much value in this comment and the Assert at this place.

+            /* Skip the original table if it's partitioned. */
+            if (part_relid == RelationGetRelid(attachRel) &&
+                attachRel->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
+                continue;
+

There isn't much point in checking this for every child in the loop. Instead,
we should remove attachRel from the attachRel_children if there are more than
one elements in the list (which means the attachRel is partitioned, may be
verify that by Asserting).

Comments on 0002 patch.
Thanks for the refactoring. The code looks really good now.

The name skipPartConstraintValidation() looks very specific to the case at
hand. The function is really checking whether existing constraints on the table
can imply the given constraints (which happen to be partition constraints). How
about PartConstraintImpliedByRelConstraint()? The idea is to pick a general
name so that the function can be used for purposes other than skipping
validation scan in future.
* This basically returns if the partrel's existing constraints, which
returns "true". Add "otherwise returns false".
   if (constr != NULL)   {       ...   }   return false;
May be you should return false when constr == NULL (I prefer !constr, but
others may have different preferences.). That should save us one level of
indentation. At the end just return whatever predicate_implied_by() returns.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Setting pd_lower in GIN metapage
Следующее
От: Mahendranath Gurram
Дата:
Сообщение: Re: [HACKERS] Regarding Postgres Dynamic Shared Memory (DSA)