From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: zheap: a new storage format for PostgreSQL |
Date: | 2018-11-02 11:12:29 |
Message-ID: | CAA4eK1Ksz_0FTi9HrJB8AFmK5KpQDYvbDcauUyZj_62fvt2itg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 1, 2018 at 7:26 PM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> On 11/01/2018 07:43 AM, Amit Kapila wrote:
> >
> > You can find the latest code at https://github.com/EnterpriseDB/zheap
> >
>
> Seems valgrind complains about a couple of places in the code - nothing
> major, might be noise, but probably worth a look.
>
I have looked at the report and one of those seems to be problematic,
so I have pushed the fix for the same. The other one for below stack
seems to be bogus:
==7569== Uninitialised value was created by a stack allocation
==7569== at 0x59043D: znocachegetattr (zheapam.c:6206)
==7569==
{
<insert_a_suppression_name_here>
Memcheck:Cond
fun:ZHeapDetermineModifiedColumns
fun:zheap_update
I have checked in the function znocachegetattr that if we initialize
the value of ret_datum, it fixes the reported error, but actually
there is no need for doing it as the code always assign the valid
value to this variable. I have left it as is for now as I am not sure
whether there is any value in doing such an initialization.
Thanks for the report.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2018-11-02 11:22:58 | Re: WIP: Avoid creation of the free space map for small tables |
Previous Message | Stephen Frost | 2018-11-02 11:08:35 | Re: WIP Patch: Add a function that returns binary JSONB as a bytea |