On Thu, Aug 20, 2015 at 3:29 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>> 4) One of the tablesample tests seems to freeze indefinitely. I
>> haven't looked into why yet. That might indeed indicate that the
>> spinlock code isn't working?
>
> The tablesample tests seem like a not-very-likely first place for such a
> thing to manifest. What I'm thinking is that there are places in there
> where we loop till we get an expected result. Offhand I thought they were
> all integer math; but if one was float and the VAX code wasn't doing what
> was expected, maybe we could blame this on float discrepancies as well.
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.
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)
--
greg
