On Fri, Mar 24, 2017 at 1:57 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> Hi Ashutosh,
>
> On 2017/03/23 21:48, Ashutosh Bapat wrote:
>>>> I have fixed all the issues reported till now.
>
> In patch 0007, the following code in have_partkey_equi_join() looks
> potentially unsafe:
>
> /*
> * If the clause refers to different partition keys from
> * both relations, it can not be used for partition-wise join.
> */
> if (ipk1 != ipk2)
> continue;
>
> /*
> * The clause allows partition-wise join if only it uses the same
> * operator family as that specified by the partition key.
> */
> if (!list_member_oid(rinfo->mergeopfamilies,
> part_scheme->partopfamily[ipk1]))
> continue;
>
> What if ipk1 and ipk2 both turn out to be -1? Accessing
> part_schem->partopfamily[ipk1] would be incorrect, no?
Thanks for the report. Surprising this should have crashed sometime,
but didn't ever. Neither it showed wrong output for queries where
partition keys were not part of equi-joins. The reason being
partopfamily[-1] had 0 in it, which when tested again
list_member_oid(rinfo->mergeopfamilies, ..) returned false. Attached
patches fix this code.
Also, I have fixed few grammar mistakes, typos, renamed variables in
PartitionSchemeData to match those in PartitionKey. I have squashed
the patches introducing IS_JOIN_REL, IS_OTHER_REL, IS_SIMPLE_REL into
one.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
