Re: Use of uninitialized variables in ExecFindPartition() for parentpartition without leaves (HEAD only) - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Use of uninitialized variables in ExecFindPartition() for parentpartition without leaves (HEAD only)
Date
Msg-id e0c4420d-5f7b-16fa-6b58-0a2e4a14d1e0@lab.ntt.co.jp
Whole thread Raw
In response to Use of uninitialized variables in ExecFindPartition() for parentpartition without leaves (HEAD only)  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Use of uninitialized variables in ExecFindPartition() for parentpartition without leaves (HEAD only)  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
Hi Michael.

On 2017/11/30 9:07, Michael Paquier wrote:
> Hi all,
> 
> Since commit 4e5fe9ad (committer Robert Haas and author Amit Langote),
> coverity has been complaining that the new code of ExecFindPartition()
> may use a set of values and isnull values which never get initialized.
> This is a state which can be easily reached with the following SQLs of
> a parent partition with no children:
> create table parent_tab (a int) partition by list ((a+0));
> insert into parent_tab values (1);
> 
> The mistake is visibly that FormPartitionKeyDatum() should be called
> even for a root partition, initializing the fields of isnull and
> values on the way. That's actually what happens in execMain.c's
> ExecFindPartition() if you look at REL_10_STABLE. So the answer would
> be to move a bit down the quick exit code. Attached is a patch.
> 
> Amit, that's your code. What do you think?

Thanks for the report.  That's clearly a bug. :-(

Your patch seems enough to fix it.  I added a test and expanded the
comment a bit in the attached updated version.

Thanks,
Amit

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] JIT compiling expressions/deform + inlining prototype v2.0
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together