On 2015-08-20 16:42:21 +0100, Greg Stark wrote:
> Ah, I was wrong. It's not the tablesample test -- I think that was the
> last one to complete. Annoyingly we don't seem to print test names
> until they finish.
>
> It was groupingsets. And it's stuck again on the same query:
>
> regression=# select
> pid,now()-query_start,now()-state_change,waiting,state,query from
> pg_stat_activity where pid <> pg_backend_pid();
>
+------+-----------------+-----------------+---------+--------+------------------------------------------------------+
> | pid | ?column? | ?column? | waiting | state |
> query |
>
+------+-----------------+-----------------+---------+--------+------------------------------------------------------+
> | 9185 | 00:53:38.571552 | 00:53:38.571552 | f | active | select
> a, b, grouping(a,b), sum(v), count(*), max(v)#|
> | | | | | | from
> gstest1 group by rollup (a,b); |
>
+------+-----------------+-----------------+---------+--------+------------------------------------------------------+
>
> It's only been stuck an hour so it's possible it's still running but
> this morning it was the same query that was running for 7 hours so I'm
> guessing not.
Interesting.
> Unfortunately I appear to have built without debugging symbols so
> it'll be a couple days before I can rebuild with symbols to get a back
> trace. (I vaguely remember when builds took hours but I don't recall
> ever having to wait 48 hours for a build even back then)
Without any further clues I'd guess it's stuck somewhere in
bipartite_match.c. That's the only place where floating point problmes
would possibly result in getting stuck.
I'm all for making sure these issues are indeed caused by platform
specific float oddities, and not a more fundamental problem. But to me
the state of this port, as evidenced in this thread, seems to be too bad
to be worthwhile keeping alive. Especially since there's really no
imaginable use case except for playing around.
Greetings,
Andres Freund
