From: Bruce Momjian Date: Tue, 19 Dec 2006 22:37:37 +0000 (+0000) Subject: Add timeline for next release to developer's FAQ. X-Git-Tag: REL8_3_BETA1~1674 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=1cacb3a0987777b3483e3d83ac07554be38b2f69;p=postgresql Add timeline for next release to developer's FAQ. --- diff --git a/doc/FAQ_DEV b/doc/FAQ_DEV index b24141ca76..f53e52017d 100644 --- a/doc/FAQ_DEV +++ b/doc/FAQ_DEV @@ -1,7 +1,7 @@ Developer's Frequently Asked Questions (FAQ) for PostgreSQL - 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) @@ -30,6 +30,7 @@ General Questions 1.16) Where can I get a copy of the SQL standards? 1.17) Where can I get technical 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 @@ -796,3 +797,24 @@ typedef struct nameData 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. + + 2.9) What is the timeline for the next major PostgreSQL release? + + The development schedule for the 8.3 release is: + + March 1, 2006 + + Initial community review of all major feature patches + April 1, 2006 + + Feature freeze, all patches must be submitted for review and + application + mid-May, 2006 + + All patches applied, beta testing begins + July, 2006 + + Release of 8.3.0 + + Patches that appear after appropriate dates are typically not applied + but held for the next major release. diff --git a/doc/src/FAQ/FAQ_DEV.html b/doc/src/FAQ/FAQ_DEV.html index ad3358fe97..8923b193ed 100644 --- a/doc/src/FAQ/FAQ_DEV.html +++ b/doc/src/FAQ/FAQ_DEV.html @@ -13,7 +13,7 @@

Developer's Frequently Asked Questions (FAQ) for PostgreSQL

-

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)
@@ -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()?

-

Normally, transactions can not see the rows they modify. This - allows UPDATE foo SET x = x + 1 to work correctly.

+

Normally, transactions can not see the rows they modify. + This allows UPDATE foo SET x = x + 1 to work + correctly.

-

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.

-

2.8) What debugging features are - available?

+

2.8) What debugging features are available?

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 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.

+ 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.

+ +

2.9) What is the timeline for the next major + PostgreSQL release?
+ +

The development schedule for the 8.3 release is:

+
+
March 1, 2006
+
Initial community review of all major feature patches
+
April 1, 2006
+
Feature freeze, all patches must be submitted for review and application
+
mid-May, 2006
+
All patches applied, beta testing begins
+
July, 2006
+
Release of 8.3.0
+
+ +

Patches that appear after appropriate dates are typically + not applied but held for the next major release.

+