From 1cacb3a0987777b3483e3d83ac07554be38b2f69 Mon Sep 17 00:00:00 2001
From: Bruce Momjian Last updated: Mon Nov 13 23:18:46 EST 2006 Last updated: Tue Dec 19 17:37:24 EST 2006 Current maintainer: Bruce Momjian (bruce@momjian.us) Normally, transactions can not see the rows they modify. This
- allows Normally, transactions can not see the rows they modify.
+ This allows However, there are cases where a transactions needs to see rows
- affected in previous parts of the transaction. This is accomplished
- using a Command Counter. Incrementing the counter allows
- transactions to be broken into pieces so each piece can see rows
- modified by previous pieces. CommandCounterIncrement()
+ However, there are cases where a transactions needs to see
+ rows affected in previous parts of the transaction. This is
+ accomplished using a Command Counter. Incrementing the counter
+ allows transactions to be broken into pieces so each piece can
+ see rows modified by previous pieces. CommandCounterIncrement()
increments the Command Counter, creating a new part of the
transaction. First, try 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 the postmaster is not running, you can actually run the
- postgres backend from the command line, and type your
- SQL statement directly. This is recommended
- only for debugging purposes. If you have compiled with debugging
- symbols, you can use a debugger to see what is happening. Because
- the backend was not started from postmaster, it is not
- running in an identical environment and locking/backend interaction
- problems might not be duplicated. If the postmaster is running, start psql in one
- window, then find the PID of the postgres
+ 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 the postmaster is not running, you can actually
+ run the postgres backend from the command line, and type
+ your SQL statement directly. This is recommended
+ only for debugging purposes. If you have compiled with
+ debugging symbols, you can use a debugger to see what is
+ happening. Because the backend was not started from postmaster,
+ it is not running in an identical environment and locking/backend
+ interaction problems might not be duplicated. If the postmaster is running, start psql in
+ one window, then find the PID of the postgres
process used by psql using 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 directory. The client profile file will be
- put in the client's current directory. Linux requires a compile with
- -DLINUX_PROFILE for proper profiling.Developer's Frequently Asked Questions (FAQ) for
PostgreSQL
-
@@ -55,6 +55,8 @@
assistance?
1.18) How do I get involved in PostgreSQL web
site development?
+ 1.19) What is the timeline for the next major
+ PostgreSQL release?
Technical Questions
@@ -937,57 +939,78 @@
2.7) What is CommandCounterIncrement()?
- UPDATE foo SET x = x + 1
to work correctly.UPDATE foo SET x = x + 1
to work
+ correctly.2.8) What debugging features are
- available?
+ 2.8) What debugging features are available?
SELECT pg_backend_pid()
.
Use a debugger to attach to the postgres PID.
- You can set breakpoints in the debugger and issue queries from the
- other. If you are looking to find the location that is generating
- an error or log message, set a breakpoint at errfinish.
-
- psql. If you are debugging postgres startup, you can
- set PGOPTIONS="-W n", then start psql. This will cause startup
- to delay for n seconds so you can attach to the process with
- the debugger, set any breakpoints, and continue through the startup
- sequence.
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 directory. The client profile + file will be put in the client's current directory. Linux + requires a compile with -DLINUX_PROFILE for proper + profiling.
+ +The development schedule for the 8.3 release is:
+Patches that appear after appropriate dates are typically + not applied but held for the next major release.
+