Horton

Re: Default Partition for Range

Dilip Kumar <dilipbalaut@gmail.com>

View thread View on postgr.es
From: Dilip Kumar <dilipbalaut@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Beena Emerson <memissemerson@gmail.com>, Rafia Sabih <rafia.sabih@enterprisedb.com>, Amit Kapila <amit.kapila16@gmail.com>, Jeevan Ladhe <jeevan.ladhe@enterprisedb.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-06-21T15:13:13Z
Lists: pgsql-hackers 
On Wed, Jun 21, 2017 at 8:08 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I think somebody should do some testing of the existing code with
> valgrind.  And then apply the list-partitioning patch and this patch,
> and do some more testing with valgrind.  It seems to be really easy to
> miss these uninitialized access problems during code review.

I think it will help,  but it may not help in all the scenarios
because most of the places we are allocating memory with palloc0 (
initialized with 0) but it never initialized with RANGE_DATUM_DEFAULT
except the first element (in the case of DEFAULT partition).  And,
later they may be considered as RANGE_DATUM_FINITE (because its value
is 0).

One solution can be that if bound is DEFAULT then initialize with
RANGE_DATUM_DEFAULT for the complete content array for that partition
bound instead of just first.  Otherwise, we need to be careful of
early exiting wherever we are looping the content array of the DEFAULT
bound.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com

Commits

  1. Allow a partitioned table to have a default partition.

  2. Add new files to nls.mk and add translation markers

  3. Improve release note text about set-returning-function changes.