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.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?
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.
+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 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 +
If the postmaster is running, start psql in
+ one window, then find the PID of the postgres
process used by psql using 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.
+ 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.
-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.