Skip site navigation (1) Skip section navigation (2)

Re: Patch - Debug builds without optimization

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Smith <greg(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch - Debug builds without optimization
Date: 2011-11-29 21:32:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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    greg(at)2ndQuadrant(dot)com   Baltimore, MD
> PostgreSQL Training, Services, and 24x7 Support
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + It's impossible for everything to be true. +

Attachment: /rtmp/doc
Description: text/x-diff (711 bytes)

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-11-29 21:35:18
Subject: Re: Allow pg_dumpall to use dumpmem.c functions, simplify exit code
Previous:From: Brar PieningDate: 2011-11-29 21:32:01
Subject: Re: Review of VS 2010 support patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group