At Wed, 08 May 2019 13:06:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote in <20190508.130636.184826233.horiguchi.kyot...@lab.ntt.co.jp> > At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote in > <20190507.204728.233299873.horiguchi.kyot...@lab.ntt.co.jp> > > Hello. > > > > At Tue, 7 May 2019 14:39:55 +0530, Rajkumar Raghuwanshi > > <rajkumar.raghuwan...@enterprisedb.com> wrote in > > <CAKcux6=ybmcntcafss_22ds1ab6mgay_quahx-nvg+_fvpm...@mail.gmail.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? regards. -- Kyotaro Horiguchi NTT Open Source Software Center