From d96398d1eb97fc3d18fb8f80b1ea09dd0af59489 Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Mon, 31 Jan 2005 22:57:17 +0000
Subject: [PATCH] Restructure debug FAQ entry.
---
doc/FAQ | 34 +++++++++++++---------------------
doc/src/FAQ/FAQ.html | 38 ++++++++++++++------------------------
2 files changed, 27 insertions(+), 45 deletions(-)
diff --git a/doc/FAQ b/doc/FAQ
index 2fe694b7176..2fe13593561 100644
--- a/doc/FAQ
+++ b/doc/FAQ
@@ -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
diff --git a/doc/src/FAQ/FAQ.html b/doc/src/FAQ/FAQ.html
index 8ea5f32443b..9c723943b12 100644
--- a/doc/src/FAQ/FAQ.html
+++ b/doc/src/FAQ/FAQ.html
@@ -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 >server.log 2>&1 &
-</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
--
GitLab