DEBUG_LEVEL (integer)
The higher this value is set, the more "debugging" output of various
sorts is generated in the server log during operation. This option is 0
by default, which means no debugging output. Values up to about 4
currently make sense.
DEBUG_PRINT_QUERY (boolean)
DEBUG_PRINT_PARSE (boolean)
DEBUG_PRINT_REWRITTEN (boolean)
DEBUG_PRINT_PLAN (boolean)
DEBUG_PRETTY_PRINT (boolean)
These flags enable various debugging output to be sent to the server
log. For each executed query, prints either the query text, the
resulting parse tree, the query rewriter output, or the execution plan.
DEBUG_PRETTY_PRINT indents these displays to produce a more readable but
much longer output format. Setting DEBUG_LEVEL above zero implicitly
turns on some of these flags.
--
I'd recommend debug level 1 and print query true for starters. Also
remember that excessive debug logging can cause performance issues, so
keep an eye on things if you crank this up on a production server.
Robert Treat
On Tue, 2002-07-30 at 00:14, Bruce Momjian wrote:
> Andrew Sullivan wrote:
> > On Fri, Jul 26, 2002 at 03:27:45PM -0700, Laurette Cisneros wrote:
> > >
> > > Is there way to track each sql statement and the user for the server?
> >
> > Sort of. Turn on query logging in the postgresql.conf file, and also
> > log connections and PID. Then, you can track back by using the PID,
> > to discovere who logged in (and therefore, who issued that query).
>
> Andrew, what postgresql.conf parameter is query logging. I don't see
> it. I see:
>
> #log_connections = false
> #log_timestamp = false
> #log_pid = false
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman@candle.pha.pa.us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
