inherited GROUP BY is busted ... I need some help here
От | Tom Lane |
---|---|
Тема | inherited GROUP BY is busted ... I need some help here |
Дата | |
Msg-id | 5098.928377620@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] inherited GROUP BY is busted ... I need some help here
Re: [HACKERS] inherited GROUP BY is busted ... I need some help here Re: [HACKERS] inherited GROUP BY is busted ... I need some help here |
Список | pgsql-hackers |
I've been chasing Chris Bitmead's coredump report from earlier today. I find that it can be reproduced very easily. For example: regression=> select f1 from int4_tbl group by f1; < no problem > regression=> select f1 from int4_tbl* group by f1; < core dump > (You may get unstable behavior rather than a reliable core dump if you are not configured --enable-cassert.) The problem seems to be in optimizer/plan/planner.c, which is responsible for creating the Sort and Group plan nodes needed to implement GROUP BY. It also has to mark the lower plan's targetlist items with resdom->reskey numbers so that the executor will know which items to use for sort keys (cf. FormSortKeys in executor/nodeSort.c). The trouble is that that latter marking is done in planner.c's make_subplanTargetList(), which *is never invoked* for a query that involves inheritance. union_planner() only calls it if the given plan involves neither UNION nor inheritance. In the UNION case, recursion into union_planner does the right thing, but not so in the inheritance case. I rewrote some of this code a couple months ago, but I find that 6.4.2 has similar problems, so at least I can say I didn't break it ;-). It seems clear that at least some of the processing that union_planner does in the simple case (the "else" part of its first big if-then-else) also needs to be done in the inheritance case (and perhaps also in the UNION case?). But I'm not sure exactly what. There's a lot going on in this chunk of code, and I don't understand very much of it. I could really use some advice... regards, tom lane
В списке pgsql-hackers по дате отправления: