Re: Crash with a CUBE query on 9.6

On 12/19/2016 09:37 PM, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>> The attached test case crashes on REL9_6_STABLE and master. On 9.5, it
>> worked.
>
> As best I can tell, this is the fault of commit 804163bc2.

Oh, the ball is right back in my court, then.

> The problem query can be simplified to
>
> SELECT
> STDDEV(DISTINCT floor(sale.cn)),
> AVG(DISTINCT floor(sale.cn))
> FROM sale,vendor
> WHERE sale.vn=vendor.vn
> GROUP BY CUBE((sale.cn,sale.dt,sale.dt),(sale.pn,sale.prc),(sale.qty,sale.vn)),sale.qty order by 1,2 ;

And further:

SELECT
STDDEV(DISTINCT g::float8),
AVG(DISTINCT g::float8)
FROM generate_series(1, 1000) g;

> The two aggregates share a "pertrans" state, but finalize_aggregates
> does not account for that and calls process_ordered_aggregate_single()
> twice on the same pertrans state. The second time crashes because we
> already deleted the tuplesort object the first time.
>
> Probably, the loop in finalize_aggregates needs to be split into two,
> one over the pertrans states and then a second one over the peragg states.
> But this code has been hacked up enough since I last looked at it that
> I'm hesitant to try to fix it myself.

Yes, that seems straightforward. I came up with the attached. Will
commit tomorrow, barring objections.

Thanks for the debugging!

- Heikki