Developer's Frequently Asked Questions (FAQ) for PostgreSQL
- Last updated: Mon Nov 13 23:18:46 EST 2006
+ Last updated: Thu Jan 4 16:00:00 EST 2007
Current maintainer: Bruce Momjian (bruce@momjian.us)
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
both the internal implementation method you plan to use, and any
user-visible changes (new syntax, etc). For complex patches, it is
important to get community feeback on your proposal before starting
- work. Failure to do so might mean your patch is rejected.
+ work. Failure to do so might mean your patch is rejected. If your work
+ is being sponsored by a company, read this article for tips on being
+ more effective.
A web site is maintained for patches awaiting review,
http://momjian.postgresql.org/cgi-bin/pgpatches, and those that are
ccsym find standard defines made by your compiler
copyright fixes copyright notices
- entab converts tabs to spaces, used by pgindent
+ entab converts spaces to tabs, used by pgindent
find_static finds functions that could be made static
find_typedef finds typedefs in the source code
find_badmacros finds macros that use braces incorrectly
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, 2007
+
+ Initial community review of all major feature patches
+ April 1, 2007
+
+ Feature freeze, all patches must be submitted for review and
+ application
+ mid-May, 2007
+
+ All patches applied, beta testing begins
+ July, 2007
+
+ Release of 8.3.0
+
+ Patches that appear after appropriate dates are typically not applied
+ but held for the next major release.
<H1>Developer's Frequently Asked Questions (FAQ) for
PostgreSQL</H1>
- <P>Last updated: Mon Nov 13 23:18:46 EST 2006</P>
+ <P>Last updated: Thu Jan 4 16:00:00 EST 2007</P>
<P>Current maintainer: Bruce Momjian (<A href=
"mailto:bruce@momjian.us">bruce@momjian.us</A>)<BR>
"http://www.postgresql.org/docs/faqs.FAQ_DEV.html">http://www.postgresql.org/docs/faqs.FAQ_DEV.html</A>.</P>
<HR>
<BR>
-
+
<H2>General Questions</H2>
<A href="#item1.1">1.1</A>) How do I get involved in PostgreSQL
assistance?<BR>
<A href="#item1.18">1.18</A>) How do I get involved in PostgreSQL web
site development?<BR>
-
+ <A href="#item1.19">1.19</A>) What is the timeline for the next major
+ PostgreSQL release?<BR>
+
<H2>Technical Questions</H2>
<A href="#item2.1">2.1</A>) How do I efficiently access information in
<A href="#item2.8">2.8</A>) What debugging features are available?<BR>
<BR>
-
+
<HR>
<H2>General Questions</H2>
in <I>doc/TODO</I> in the source distribution or at <A href=
"http://www.postgresql.org/docs/faqs.TODO.html">
http://www.postgresql.org/docs/faqs.TODO.html</A>.
-
+
<P>You can learn more about these features by consulting the
archives, the SQL standards and the recommend texts (see <A href=
use, and any user-visible changes (new syntax, etc). For complex
patches, it is important to get community feeback on your proposal
before starting work. Failure to do so might mean your patch is
- rejected.</P>
+ rejected. If your work is being sponsored by a company, read this
+ <a href="http://momjian.us/main/writings/pgsql/company_contributions/">
+ article</a> for tips on being more effective.</P>
<P>A web site is maintained for patches awaiting review,
<a href="http://momjian.postgresql.org/cgi-bin/pgpatches">
those that are being kept for the next release,
<a href="http://momjian.postgresql.org/cgi-bin/pgpatches_hold">
http://momjian.postgresql.org/cgi-bin/pgpatches_hold</a>.</P>
-
+
<H3 id="item1.5">1.5) I've developed a patch, what next?</H3>
<P>You will need to submit the patch to pgsql-patches@postgresql.org. It
<I>src/tools/make_diff/difforig</I> useful. (Unified diffs are only
preferable if the file changes are single-line changes and do not
rely on surrounding lines.)</li>
-
+
<li>PostgreSQL is licensed under a BSD license, so any submissions must
conform to the BSD license to be included. If you use code that is
available under some other license that is BSD compatible (eg. public
ccsym find standard defines made by your compiler
copyright fixes copyright notices
- entab converts tabs to spaces, used by pgindent
+ entab converts spaces to tabs, used by pgindent
find_static finds functions that could be made static
find_typedef finds typedefs in the source code
find_badmacros finds macros that use braces incorrectly
<P>We try to build on as many different canonical distributions as we can.
Currently we are able to build on Red Hat Linux 9, RHEL 3 and above,
and all Fedora Core Linux releases.</P>
-
+
<P>To test the binaries, we install them on our local machines and run
regression tests. If the package builders uses postgres user to build the
rpms, then it is possible to run regression tests during RPM builds.</P>
is possible. Only the standard released 'official to that release'
compiler is used -- and only the standard official kernel is used as
well.</P>
-
+
<P>PGDG RPM Building Project does not build RPMs for Mandrake .</P>
<P>We usually have only one SRPM for all platforms. This is because of our
limited resources. However, on some cases, we may distribute different
SRPMs for different platforms, depending on possible compilation problems,
especially on older distros.</P>
-
+
<P>Please note that this is a volunteered job -- We are doing our best to
keep packages up to date. We, at least, provide SRPMs for all platforms.
For example, if you do not find a RHEL 4 x86_64 RPM in our FTP site, it
<PRE>
<CODE> List *list;
ListCell *i;
-
+
foreach(i, list)
{
Var *var = lfirst(i);
<H3 id="item2.7">2.7) What is CommandCounterIncrement()?</H3>
- <P>Normally, transactions can not see the rows they modify. This
- allows <CODE>UPDATE foo SET x = x + 1</CODE> to work correctly.</P>
+ <P>Normally, transactions can not see the rows they modify.
+ This allows <CODE>UPDATE foo SET x = x + 1</CODE> to work
+ correctly.</P>
- <P>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. <I>CommandCounterIncrement()</I>
+ <P>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. <I>CommandCounterIncrement()</I>
increments the Command Counter, creating a new part of the
transaction.</P>
- <H3 id="item2.8">2.8) What debugging features are
- available?</H3>
+ <H3 id="item2.8">2.8) What debugging features are available?</H3>
<P>First, try 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>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 the <I>postmaster</I> is not running, you can actually run the
- <I>postgres</I> backend from the command line, and type your
- <SMALL>SQL</SMALL> statement directly. This is recommended
- <B>only</B> 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 <I>postmaster</I>, it is not
- running in an identical environment and locking/backend interaction
- problems might not be duplicated.</P>
-
- <P>If the <I>postmaster</I> is running, start <I>psql</I> in one
- window, then find the <SMALL>PID</SMALL> of the <I>postgres</I>
+ option, many <I>assert()</I>s monitor the progress of the
+ backend and halt the program when something unexpected occurs.</P>
+
+ <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 the <I>postmaster</I> is not running, you can actually
+ run the <I>postgres</I> backend from the command line, and type
+ your <SMALL>SQL</SMALL> statement directly. This is recommended
+ <B>only</B> 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 <I>postmaster</I>,
+ it is not running in an identical environment and locking/backend
+ interaction problems might not be duplicated.</P>
+
+ <P>If the <I>postmaster</I> is running, start <I>psql</I> in
+ one window, then find the <SMALL>PID</SMALL> of the <I>postgres</I>
process used by <I>psql</I> using <CODE>SELECT pg_backend_pid()</CODE>.
Use a debugger to attach to the <I>postgres</I> <SMALL>PID</SMALL>.
- 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 <I>errfinish</I>.
-
- <I>psql</I>. If you are debugging <I>postgres</I> startup, you can
- set PGOPTIONS="-W n", then start <I>psql</I>. This will cause startup
- to delay for <I>n</I> seconds so you can attach to the process with
- the debugger, set any breakpoints, and continue through the startup
- sequence.</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</I> directory. The client profile file will be
- put in the client's current directory. Linux requires a compile with
- <I>-DLINUX_PROFILE</I> for proper profiling.</P>
+ 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
+ <I>errfinish</I>.
+
+ <I>psql</I>. If you are debugging <I>postgres</I> startup, you
+ can set PGOPTIONS="-W n", then start <I>psql</I>. This will
+ cause startup to delay for <I>n</I> seconds so you can attach
+ to the process with the debugger, set any breakpoints, and
+ continue through the startup sequence.</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</I> directory. The client profile
+ file will be put in the client's current directory. Linux
+ requires a compile with <I>-DLINUX_PROFILE</I> for proper
+ profiling.</P>
+
+ <H3 id="item2.9">2.9) What is the timeline for the next major
+ PostgreSQL release?<BR>
+
+ <P>The development schedule for the 8.3 release is:</P>
+ <DL>
+ <DD>March 1, 2007</DD>
+ <DT>Initial community review of all major feature patches</DT>
+ <DD>April 1, 2007</DD>
+ <DT>Feature freeze, all patches must be submitted for review and application</DT>
+ <DD>mid-May, 2007</DD>
+ <DT>All patches applied, beta testing begins</DT>
+ <DD>July, 2007</DD>
+ <DT>Release of 8.3.0</DT>
+ </DL>
+
+ <P>Patches that appear after appropriate dates are typically
+ not applied but held for the next major release.</P>
+
</BODY>
</HTML>