On Wed, Jun 21, 2017 at 8:08 PM, Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
