Re: [HACKERS] advanced partition matching algorithm forpartition-wise join - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
Date
Msg-id CAExHW5v6ir7y0eZe5qKBX87=Xbv2qZs2ddavkMRfWPeQTG2k7w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] advanced partition matching algorithm forpartition-wise join  (amul sul <sulamul@gmail.com>)
Responses Re: [HACKERS] advanced partition matching algorithm forpartition-wise join
List pgsql-hackers


On Thu, Mar 7, 2019 at 8:20 PM amul sul <sulamul@gmail.com> wrote:


On Thu, Mar 7, 2019 at 1:02 PM amul sul <sulamul@gmail.com> wrote:
Thanks Rajkumar,

I am looking into this.


The crash happens when none of the if-else branch of handle_missing_partition()
evaluates and returns merged_index unassigned.

Let me explain, in Rajkumar 's test case, the join type is JOIN_INNER.  When
only outer rel has null partition, merge_null_partitions() function calls
handle_missing_partition() with missing_side_inner = false and
missing_side_outer = false

Both missing_side_ variables being false when the NULL partition is missing on the inner side looks suspicious. I guess from the variable names that the missing_side_inner should be true in this case. 
 
argument value which fails to set merged_index.

In the attached patch, I tried to fix this case by setting merged_index
explicitly which fixes the reported crash. 

I expect handle_missing_partition() to set the merged_index always. In your patches, I don't see that function in your patches is setting it explicitly. If we are setting merged_index explicitly somewhere else, other places may miss that explicit assignment. So it's better to move it inside this function.
 
--
Best Wishes,
Ashutosh Bapat

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [HACKERS] WAL logging problem in 9.4.3?
Next
From: Tomas Vondra
Date:
Subject: Re: [HACKERS] PATCH: multivariate histograms and MCV lists