I have applied the attached patch to help make suggestsions for server
developers. I didn't reproduce most of the text because it was already
listed with the options. Let me know if you want additional text.
---------------------------------------------------------------------------
Greg Smith wrote:
> On 06/16/2011 10:10 AM, Tom Lane wrote:
> > I could see providing some other nonstandard configure switch that
> > changed the default -O level ... but realistically, would that do
> > anything that you couldn't already do by setting CFLAGS, ie
> >
> > ./configure CFLAGS="-O0 -g"
> >
>
> I think a small discussion of the issue Radek ran into is appropriate to
> put somewhere, with this example. The install procedure section of the
> docs already includes a CFLAGS example:
>
> ./configure CC=/opt/bin/gcc CFLAGS='-O2 -pipe'
>
> There is also a section talking about setting options like
> --enable-cassert in the Developer's FAQ. Looking at all the info out
> there about developer/debug builds, it's really kind of sketchy and
> distributed though. No one place that pulls all the most common things
> people need together into one resource.
>
> What seems like the idea solution here is to add a new section to the
> install procedure with brief coverage of this entire area. Here's a
> prototype of text that might go there:
>
> = Installation for development and debugging =
>
> When modifying the PostgreSQL source code, or when trying to find the
> source of a bug in the program, it may be helpful to build the program
> in a way that makes this process easier. There are build-time only
> changes that enable better error checking and debugging, including:
>
> Pass --enable-cassert to configure. This can make bugs more visible,
> because they cause operations to abort with a clear error. That makes
> some types of debugging much easier. This is risky on a production
> server, as described in the documentation for this parameter.
>
> Pass --enable-debug to configure. This provides better information about
> what the server is doing when looking at it using a debugger. It's less
> risky to a production server than enabling assertions, and it normally
> has less of a performance impact hgtoo. See its documentation for more
> details.
>
> Disable compiler optimization. When using a debugger to trace into the
> source code of the server, steps may optimized away by the normal build
> process. In some situations --enable-debug will disable such
> optimization, but this is not always the case. Specifically disabling
> optimization is possible with many compilers by setting the compiler
> flags when configuration the source code build, such as:
>
> ./configure CFLAGS="-O0 -g"
>
> This example for the gcc compiler disables optimizations, and tells the
> compiler to provide extra debugging information most useful with the gdb
> debugger.
>
> --
> Greg Smith 2ndQuadrant US [email protected] Baltimore, MD
> PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
>
>
>
> --
> Sent via pgsql-hackers mailing list ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml
new file mode 100644
index 41b9009..16fbdc6
*** a/doc/src/sgml/installation.sgml
--- b/doc/src/sgml/installation.sgml
*************** su - postgres
*** 1412,1417 ****
--- 1412,1426 ----
</varlistentry>
</variablelist>
</para>
+
+ <note>
+ <para>
+ Server developers should consider using the configure options
+ <option>--enable-cassert</> and <option>--enable-debug</> to enhance the
+ ability to detect and debug server errors. They should also consider
+ running configure with <literal>CFLAGS="-O0 -g"</>.
+ </para>
+ </note>
</step>
<step id="build">
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
