mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Restructure debug FAQ entry.

Browse Source
This commit is contained in:
Bruce Momjian 2005-01-31 22:57:17 +00:00
parent 1f7aa643b6
commit d96398d1eb
2 changed files with 27 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
doc/FAQ
View File

@ -1,7 +1,7 @@
Frequently Asked Questions (FAQ) for PostgreSQL
Last updated: Mon Jan 31 15:40:24 EST 2005
Last updated: Mon Jan 31 17:57:02 EST 2005
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
@ -383,24 +383,20 @@
3.4) What debugging features are available?
PostgreSQL has several features that report status information that
can be valuable for debugging purposes.
There are many log_* server configuration variables that enable
printing of query and process statistics which can be very useful for
debugging and performance measurements.
First, by running configure with the --enable-cassert option, many
assert()s monitor the progress of the backend and halt the program
when something unexpected occurs.
The following detailed debug instructions are to be used to provide
more detailed information for server developers debugging a problem
Both postmaster and postgres have several debug options available.
First, whenever you start postmaster, make sure you send the standard
output and error to a log file, like:
cd /usr/local/pgsql
./bin/postmaster >server.log 2>&1 &
This will put a server.log file in the top-level PostgreSQL directory.
This file contains useful information about problems or errors
encountered by the server. Postmaster has a -d option that allows even
more detailed information to be reported. The -d option takes a number
that specifies the debug level. Be warned that high debug level values
It is also possible to debug the server if it isn't operating
properly. First, by running configure with the --enable-cassert
option, many assert()s monitor the progress of the backend and halt
the program when something unexpected occurs.
The postmaster has a -d option that allows even more detailed
information to be reported. The -d option takes a number that
specifies the debug level. Be warned that high debug level values
generate large log files.
If postmaster is not running, you can actually run the postgres
@ -421,10 +417,6 @@
process with the debugger, set any breakpoints, and continue through
the startup sequence.
There are several log_* server configuration variables that enable
printing of process statistics which can be very useful for debugging
and performance measurements.
You can also compile with profiling to see what functions are taking
execution time. The backend profile files will be deposited in the
pgsql/data/base/dbname directory. The client profile file will be put

38
doc/src/FAQ/FAQ.html
View File

@ -10,7 +10,7 @@
alink="#0000ff">
<H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
<P>Last updated: Mon Jan 31 15:40:24 EST 2005</P>
<P>Last updated: Mon Jan 31 17:57:02 EST 2005</P>
<P>Current maintainer: Bruce Momjian (<A href=
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)
@ -519,29 +519,23 @@
<H4><A name="3.4">3.4</A>) What debugging features are
available?</H4>
<P>PostgreSQL has several features that report status information
that can be valuable for debugging purposes.</P>
<P>There are many <CODE>log_*</CODE> server configuration variables
that enable printing of query and process statistics which can be
very useful for debugging and performance measurements.</P>
<P>First, by running <I>configure</I> with the --enable-cassert
<P><B>The following detailed debug instructions are to be used to
provide more detailed information for server developers debugging a
problem<B></P>
<P>It is also possible to debug the server if it isn't operating
properly. First, by running <I>configure</I> with the --enable-cassert
option, many <I>assert()</I>s monitor the progress of the backend
and halt the program when something unexpected occurs.</P>
<P>Both <I>postmaster</I> and <I>postgres</I> have several debug
options available. First, whenever you start <I>postmaster</I>,
make sure you send the standard output and error to a log file,
like:</P>
<PRE>
cd /usr/local/pgsql
./bin/postmaster &gt;server.log 2&gt;&amp;1 &amp;
</PRE>
<P>This will put a server.log file in the top-level PostgreSQL
directory. This file contains useful information about problems or
errors encountered by the server. <I>Postmaster</I> has a <I>-d</I>
option that allows even more detailed information to be reported.
The <I>-d</I> option takes a number that specifies the debug level.
Be warned that high debug level values generate large log
files.</P>
The <I>postmaster</I> has a <I>-d</I> option that allows even more
detailed information to be reported. The <I>-d</I> option takes a
number that specifies the debug level. Be warned that high debug
level values generate large log files.</P>
<P>If <I>postmaster</I> is not running, you can actually run the
<I>postgres</I> backend from the command line, and type your
@ -565,10 +559,6 @@
the debugger, set any breakpoints, and continue through the startup
sequence.</P>
<P>There are several <CODE>log_*</CODE> server configuration variables
that enable printing of process statistics which can be very useful
for debugging and performance measurements.</P>
<P>You can also compile with profiling to see what functions are
taking execution time. The backend profile files will be deposited
in the <I>pgsql/data/base/dbname</I> directory. The client profile