| From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> | 
|---|---|
| To: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, Simon Riggs <simon(at)2ndquadrant(dot)com> | 
| Cc: | pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Increasing the length of | 
| Date: | 2004-11-11 15:20:43 | 
| Message-ID: | 1100186444.5506.20.camel@camel | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Wed, 2004-11-10 at 17:57, Andrew Sullivan wrote:
> On Wed, Nov 10, 2004 at 05:51:01PM -0500, Andrew Sullivan wrote:
> > log_statement_after_min_duration (integer) -- which did what Simon
> > wants.  
> 
> Uh, well, not what Simon wants, of course, but which gave us a useful
> capability anyway.  I agree that the full-bore profiling for the DBA
> would be awful nice.  But in its absence, if you could see your
> long-running query in the log after a minute, and then go do an
> EXPLAIN and realise "uh-oh, that's gonna take 3 days to complete" and
> kill it, it would be a big help.  
> 
I believe the geeky non-helpful answer is to attach to the process with
gdb and do p debug_query_string which I believe will show you said long
running query. (Someone who actually hacks C can correct me on that, but
I believe I've done it that way before).  
Of course that idea lead me to wondering why we couldn't have a function
that could look at a connection (well, either by way of pid or possibly
transaction id) and show the current query being executed. 
Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-11-11 15:24:34 | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) | 
| Previous Message | Oleg Bartunov | 2004-11-11 14:42:01 | Re: ltree PostgreSQL Module |