Re: Statistical aggregate functions are not working with PARTIAL aggregation

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: andrew(dot)dunstan(at)2ndquadrant(dot)com
Cc: stark(at)mit(dot)edu, rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Statistical aggregate functions are not working with PARTIAL aggregation
Date: 2019-05-09 02:18:12
Message-ID: 20190509.111812.103036293.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello. There is an unfortunate story on this issue.

At Wed, 8 May 2019 14:56:25 -0400, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote in <7969b496-096a-bf9b-2a03-4706baa4c48e(at)2ndQuadrant(dot)com>
>
> On 5/8/19 12:41 PM, Greg Stark wrote:
> > Don't we have a build farm animal that runs under valgrind that would
> > have caught this?
> >
> >
>
> There are two animals running under valgrind: lousyjack and skink.

Valgrind doesn't detect the overruning read since the block
doesn't has 'MEMNOACCESS' region, since the requested size is
just 64 bytes.

Thus the attached patch let valgrind detect the overrun.

==00:00:00:22.959 20254== VALGRINDERROR-BEGIN
==00:00:00:22.959 20254== Conditional jump or move depends on uninitialised value(s)
==00:00:00:22.959 20254== at 0x88A838: ExecInterpExpr (execExprInterp.c:1553)
==00:00:00:22.959 20254== by 0x88AFD5: ExecInterpExprStillValid (execExprInterp.c:1769)
==00:00:00:22.959 20254== by 0x8C3503: ExecEvalExprSwitchContext (executor.h:307)
==00:00:00:22.959 20254== by 0x8C4653: advance_aggregates (nodeAgg.c:679)

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment Content-Type Size
let_valgrind_find_the_overrun.patch text/x-patch 581 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-09 02:37:05 Re: Fuzzy thinking in is_publishable_class
Previous Message Michael Paquier 2019-05-09 01:32:51 Re: Wrong return code in vacuumdb when multiple jobs are used