Re: Default Partition for Range

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Beena Emerson <memissemerson(at)gmail(dot)com>, Rafia Sabih <rafia(dot)sabih(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Jeevan Ladhe <jeevan(dot)ladhe(at)enterprisedb(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Default Partition for Range
Date: 2017-06-21 15:13:13
Message-ID: CAFiTN-sttETi8FSEOHCqpOhXTjJac3rkNrH7VirAvJ6SVjD_nA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 21, 2017 at 8:08 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-06-21 15:30:46 Re: pg_bsd_indent 2.0 is available from git.postgresql.org
Previous Message Alvaro Herrera 2017-06-21 15:11:57 Re: Shortened URLs for commit messages