Re: [BUGS] Crash with a CUBE query on 9.6
От | Heikki Linnakangas |
---|---|
Тема | Re: [BUGS] Crash with a CUBE query on 9.6 |
Дата | |
Msg-id | 8821dc7b-50e0-b983-1590-344108b20855@iki.fi обсуждение исходный текст |
Ответ на | Re: [BUGS] Crash with a CUBE query on 9.6 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [BUGS] Crash with a CUBE query on 9.6
Re: [BUGS] Crash with a CUBE query on 9.6 |
Список | pgsql-bugs |
On 12/19/2016 09:37 PM, Tom Lane wrote: > Heikki Linnakangas <hlinnaka@iki.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Вложения
В списке pgsql-bugs по дате отправления: