From: | Andrew Puschak <apuschak(at)gmail(dot)com> |
---|---|
To: | Sameer Kumar <sameer(dot)kumar(at)ashnik(dot)com> |
Cc: | Thomas Kellerer <spam_eater(at)gmx(dot)net>, "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org> |
Subject: | Re: Mystery SELECT * query |
Date: | 2014-01-21 12:37:15 |
Message-ID: | CALFZoBv78QRrTbrkqcTzHxO_mCmh5foMU-GOfmM5_1bODrS-rQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
On Mon, Jan 20, 2014 at 10:46 PM, Sameer Kumar <sameer(dot)kumar(at)ashnik(dot)com>wrote:
> Try to set a statement timeout and see which part of code/application
> fails when this query is timed-out.
>
> Will that be a logical way to figure out from where the query is being
> fired?
>
Yes, that makes sense, but unfortunately I don't have access to the system
to test it. I did test all the queries that were written in the code I was
given and none of them created SELECT * FROM queries, so I also suspected
it was somewhere in the stack but was unable to learn what the code is
being run in besides just being told its pasqual and ODBC. Hopefully it
won't be a problem.
Thanks,
Andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Rohit Goyal | 2014-01-21 14:52:30 | Request for error explaination || Adding a new integer in indextupleData Structure |
Previous Message | Sameer Kumar | 2014-01-21 03:46:33 | Re: Mystery SELECT * query |