|
13 | 13 | <H1>Developer's Frequently Asked Questions (FAQ) for
|
14 | 14 | PostgreSQL</H1>
|
15 | 15 |
|
16 |
| - <P>Last updated: Mon Nov 13 23:18:46 EST 2006</P> |
| 16 | + <P>Last updated: Tue Dec 19 17:37:24 EST 2006</P> |
17 | 17 |
|
18 | 18 | <P>Current maintainer: Bruce Momjian (<A href=
|
19 | 19 | "mailto:bruce@momjian.us">bruce@momjian.us</A>)<BR>
|
@@ -55,6 +55,8 @@ <H2>General Questions</H2>
|
55 | 55 | assistance?<BR>
|
56 | 56 | <A href="#item1.18">1.18</A>) How do I get involved in PostgreSQL web
|
57 | 57 | site development?<BR>
|
| 58 | + <A href="#item1.19">1.19</A>) What is the timeline for the next major |
| 59 | + PostgreSQL release?<BR> |
58 | 60 |
|
59 | 61 |
|
60 | 62 | <H2>Technical Questions</H2>
|
@@ -937,57 +939,78 @@ <H3 id="item2.6">2.6) What is ereport()?</H3>
|
937 | 939 |
|
938 | 940 | <H3 id="item2.7">2.7) What is CommandCounterIncrement()?</H3>
|
939 | 941 |
|
940 |
| - <P>Normally, transactions can not see the rows they modify. This |
941 |
| - allows <CODE>UPDATE foo SET x = x + 1</CODE> to work correctly.</P> |
| 942 | + <P>Normally, transactions can not see the rows they modify. |
| 943 | + This allows <CODE>UPDATE foo SET x = x + 1</CODE> to work |
| 944 | + correctly.</P> |
942 | 945 |
|
943 |
| - <P>However, there are cases where a transactions needs to see rows |
944 |
| - affected in previous parts of the transaction. This is accomplished |
945 |
| - using a Command Counter. Incrementing the counter allows |
946 |
| - transactions to be broken into pieces so each piece can see rows |
947 |
| - modified by previous pieces. <I>CommandCounterIncrement()</I> |
| 946 | + <P>However, there are cases where a transactions needs to see |
| 947 | + rows affected in previous parts of the transaction. This is |
| 948 | + accomplished using a Command Counter. Incrementing the counter |
| 949 | + allows transactions to be broken into pieces so each piece can |
| 950 | + see rows modified by previous pieces. <I>CommandCounterIncrement()</I> |
948 | 951 | increments the Command Counter, creating a new part of the
|
949 | 952 | transaction.</P>
|
950 | 953 |
|
951 |
| - <H3 id="item2.8">2.8) What debugging features are |
952 |
| - available?</H3> |
| 954 | + <H3 id="item2.8">2.8) What debugging features are available?</H3> |
953 | 955 |
|
954 | 956 | <P>First, try running <I>configure</I> with the --enable-cassert
|
955 |
| - option, many <I>assert()</I>s monitor the progress of the backend |
956 |
| - and halt the program when something unexpected occurs.</P> |
957 |
| - |
958 |
| - <P>The <I>postmaster</I> has a <I>-d</I> option that allows even more |
959 |
| - detailed information to be reported. The <I>-d</I> option takes a |
960 |
| - number that specifies the debug level. Be warned that high debug |
961 |
| - level values generate large log files.</P> |
962 |
| - |
963 |
| - <P>If the <I>postmaster</I> is not running, you can actually run the |
964 |
| - <I>postgres</I> backend from the command line, and type your |
965 |
| - <SMALL>SQL</SMALL> statement directly. This is recommended |
966 |
| - <B>only</B> for debugging purposes. If you have compiled with debugging |
967 |
| - symbols, you can use a debugger to see what is happening. Because |
968 |
| - the backend was not started from <I>postmaster</I>, it is not |
969 |
| - running in an identical environment and locking/backend interaction |
970 |
| - problems might not be duplicated.</P> |
971 |
| - |
972 |
| - <P>If the <I>postmaster</I> is running, start <I>psql</I> in one |
973 |
| - window, then find the <SMALL>PID</SMALL> of the <I>postgres</I> |
| 957 | + option, many <I>assert()</I>s monitor the progress of the |
| 958 | + backend and halt the program when something unexpected occurs.</P> |
| 959 | + |
| 960 | + <P>The <I>postmaster</I> has a <I>-d</I> option that allows |
| 961 | + even more detailed information to be reported. The <I>-d</I> |
| 962 | + option takes a number that specifies the debug level. Be warned |
| 963 | + that high debug level values generate large log files.</P> |
| 964 | + |
| 965 | + <P>If the <I>postmaster</I> is not running, you can actually |
| 966 | + run the <I>postgres</I> backend from the command line, and type |
| 967 | + your <SMALL>SQL</SMALL> statement directly. This is recommended |
| 968 | + <B>only</B> for debugging purposes. If you have compiled with |
| 969 | + debugging symbols, you can use a debugger to see what is |
| 970 | + happening. Because the backend was not started from <I>postmaster</I>, |
| 971 | + it is not running in an identical environment and locking/backend |
| 972 | + interaction problems might not be duplicated.</P> |
| 973 | + |
| 974 | + <P>If the <I>postmaster</I> is running, start <I>psql</I> in |
| 975 | + one window, then find the <SMALL>PID</SMALL> of the <I>postgres</I> |
974 | 976 | process used by <I>psql</I> using <CODE>SELECT pg_backend_pid()</CODE>.
|
975 | 977 | Use a debugger to attach to the <I>postgres</I> <SMALL>PID</SMALL>.
|
976 |
| - You can set breakpoints in the debugger and issue queries from the |
977 |
| - other. If you are looking to find the location that is generating |
978 |
| - an error or log message, set a breakpoint at <I>errfinish</I>. |
979 |
| - |
980 |
| - <I>psql</I>. If you are debugging <I>postgres</I> startup, you can |
981 |
| - set PGOPTIONS="-W n", then start <I>psql</I>. This will cause startup |
982 |
| - to delay for <I>n</I> seconds so you can attach to the process with |
983 |
| - the debugger, set any breakpoints, and continue through the startup |
984 |
| - sequence.</P> |
985 |
| - |
986 |
| - <P>You can also compile with profiling to see what functions are |
987 |
| - taking execution time. The backend profile files will be deposited |
988 |
| - in the <I>pgsql/data</I> directory. The client profile file will be |
989 |
| - put in the client's current directory. Linux requires a compile with |
990 |
| - <I>-DLINUX_PROFILE</I> for proper profiling.</P> |
| 978 | + You can set breakpoints in the debugger and issue queries from |
| 979 | + the other. If you are looking to find the location that is |
| 980 | + generating an error or log message, set a breakpoint at |
| 981 | + <I>errfinish</I>. |
| 982 | + |
| 983 | + <I>psql</I>. If you are debugging <I>postgres</I> startup, you |
| 984 | + can set PGOPTIONS="-W n", then start <I>psql</I>. This will |
| 985 | + cause startup to delay for <I>n</I> seconds so you can attach |
| 986 | + to the process with the debugger, set any breakpoints, and |
| 987 | + continue through the startup sequence.</P> |
| 988 | + |
| 989 | + <P>You can also compile with profiling to see what functions |
| 990 | + are taking execution time. The backend profile files will be |
| 991 | + deposited in the <I>pgsql/data</I> directory. The client profile |
| 992 | + file will be put in the client's current directory. Linux |
| 993 | + requires a compile with <I>-DLINUX_PROFILE</I> for proper |
| 994 | + profiling.</P> |
| 995 | + |
| 996 | + <H3 id="item2.9">2.9) What is the timeline for the next major |
| 997 | + PostgreSQL release?<BR> |
| 998 | + |
| 999 | + <P>The development schedule for the 8.3 release is:</P> |
| 1000 | + <DL> |
| 1001 | + <DD>March 1, 2006</DD> |
| 1002 | + <DT>Initial community review of all major feature patches</DT> |
| 1003 | + <DD>April 1, 2006</DD> |
| 1004 | + <DT>Feature freeze, all patches must be submitted for review and application</DT> |
| 1005 | + <DD>mid-May, 2006</DD> |
| 1006 | + <DT>All patches applied, beta testing begins</DT> |
| 1007 | + <DD>July, 2006</DD> |
| 1008 | + <DT>Release of 8.3.0</DT> |
| 1009 | + </DL> |
| 1010 | + |
| 1011 | + <P>Patches that appear after appropriate dates are typically |
| 1012 | + not applied but held for the next major release.</P> |
| 1013 | + |
991 | 1014 | </BODY>
|
992 | 1015 | </HTML>
|
993 | 1016 |
|
0 commit comments