<p dir="ltr">On Wed, Sep 7, 2016 at 4:37 PM, Robins Tharakan <<a
href="mailto:tharakan@gmail.com">tharakan@gmail.com</a>>wrote:<br /><blockquote><p dir="ltr">><br
/></blockquote><pdir="ltr">> Hi,<br /> ><br /> > An SQL (with only information_schema related JOINS) when
triggered,runs with max CPU (and never ends - killed after 2 days).<br /> > - It runs similarly (very slow) on a
replicatedserver that acts as a read-only slave.<br /> > - Top shows only postgres as hitting max CPU (nothing
else).When query killed, CPU near 0%.<br /> > - When the DB is restored on a separate test server (with the exact
postgresql.conf)the same query works fine.<br /> > - There is no concurrent usage on the replicated /
test server (althoughthe primary is a Production server and has concurrent users).<br /> ><br /> > Questions:<br
/>> - If this was a postgres bug or a configuration issue, query on the restored DB should have been slow too. Is
theresomething very basic I am missing here?<br /> ><br /> > If someone asks for I could provide SQL + EXPLAIN,
butit feels irrelevant here. I amn't looking for a specific solution but what else should I be looking for here? <br
/><pdir="ltr">strace -ttt -T -y the process to see what system calls it is making. If it is not doing many systme
calls,or they are uninformative, then attach the gdb debugger to it and periodically interrupt the process (ctrl c) and
takea back trace (bt), then restart it (c) and repeat. If all the stack traces look similar, you will know where the
timeis going. <br /> <br /> Cheers, <p dir="ltr">Jeff<br />
