Re: Statistical aggregate functions are not working with PARTIAL aggregation

On Wed, May 08, 2019 at 01:09:23PM +0900, Kyotaro HORIGUCHI wrote:
>At Wed, 08 May 2019 13:06:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20190508(dot)130636(dot)184826233(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
>> At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20190507(dot)204728(dot)233299873(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
>> > Hello.
>> >
>> > At Tue, 7 May 2019 14:39:55 +0530, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com> wrote in <CAKcux6=YBMCntcafSs_22dS1ab6mGay_QUaHx-nvg+_FVPMg3Q(at)mail(dot)gmail(dot)com>
>> > > Hi,
>> > > As this issue is reproducible without partition-wise aggregate also,
>> > > changing email subject from "Statistical aggregate functions are not
>> > > working with partitionwise aggregate " to "Statistical aggregate functions
>> > > are not working with PARTIAL aggregation".
>> > >
>> > > original reported test case and discussion can be found at below link.
>> > > https://www.postgresql.org/message-id/flat/CAKcux6%3DuZEyWyLw0N7HtR9OBc-sWEFeByEZC7t-KDf15FKxVew%40mail.gmail.com
>> >
>> > The immediate reason for the behavior seems that
>> > EEOP_AGG_STRICT_INPUT_CHECK_ARGS considers non existent second
>> > argument as null, which is out of arguments list in
>> > trans_fcinfo->args[].
>> >
>> > The invalid deserialfn_oid case in ExecBuildAggTrans, it
>> > initializes args[1] using the second argument of the functoin
>> > (int8pl() in the case) so the correct numTransInputs here is 1,
>> > not 2.
>> >
>> > I don't understand this fully but at least the attached patch
>> > makes the test case work correctly and this seems to be the only
>> > case of this issue.
>>
>> This behavior is introduced by 69c3936a14 (in v11). At that time
>> FunctionCallInfoData is pallioc0'ed and has fixed length members
>> arg[6] and argnull[7]. So nulls[1] is always false even if nargs
>> = 1 so the issue had not been revealed.
>>
>> After introducing a9c35cf85c (in v12) the same check is done on
>> FunctionCallInfoData that has NullableDatum args[] of required
>> number of elements. In that case args[1] is out of palloc'ed
>> memory so this issue has been revealed.
>>
>> In a second look, I seems to me that the right thing to do here
>> is setting numInputs instaed of numArguments to numTransInputs in
>> combining step.
>
>By the way, as mentioned above, this issue exists since 11 but
>harms at 12. Is this an open item, or older bug?
>

It is an open item - there's a section for older bugs, but considering
it's harmless in 11 (at least that's my understanding from the above
discussion) I've added it as a regular open item.

I've linked it to a9c35cf85c, which seems to be the culprit commit.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services