Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition() - Mailing list pgsql-hackers
From | Ashutosh Bapat |
---|---|
Subject | Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition() |
Date | |
Msg-id | CAFjFpRe_GKCHGwbNt6NgwPuwW1qM1Fhuo2y5Mzwv7_99DfuX7A@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition() (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Responses |
Re: [HACKERS] A bug in mapping attributes in ATExecAttachPartition()
|
List | 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 by date: