Re: Why does WAL_DEBUG macro need to be defined by default? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Why does WAL_DEBUG macro need to be defined by default?
Date
Msg-id CA+Tgmoaex_j98yfKpTM3GQZ9-g_H_H1H4abFYz8cofObn4vfYg@mail.gmail.com
Whole thread Raw
In response to Re: Why does WAL_DEBUG macro need to be defined by default?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Why does WAL_DEBUG macro need to be defined by default?  (Bruce Momjian <bruce@momjian.us>)
Re: Why does WAL_DEBUG macro need to be defined by default?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Oct 7, 2011 at 4:06 PM, Bruce Momjian <bruce@momjian.us> wrote:
> Robert Haas wrote:
>> On Fri, Oct 7, 2011 at 1:03 PM, Kevin Grittner
>> <Kevin.Grittner@wicourts.gov> wrote:
>> > Robert Haas <robertmhaas@gmail.com> wrote:
>> >> The funny thing is that I've been thinking all of these months
>> >> about how convenient it is that we defined WAL_DEBUG in debug
>> >> builds
>> >
>> > IMO, --enable-debug should not do anything but include debugging
>> > symbols. ?The ability to get a useful stack trace from a production
>> > crash, without compromising performance, is just too important by
>> > itself to consider conditioning any other behavior on it.
>>
>> So, should I go revert this change in head and 9.1, or does anyone
>> else want to argue for Heikki's position that we should just leave it
>> on, on the theory that it's too cheap to matter?
>
> I would just fix it in head.

That just seems weird.  Either it's cheap enough not to matter (in
which case there's no reason to revert that change at all) or it's
expensive enough to matter (in which case presumably we don't want to
leave it on in 9.1 for the 5 years or so it remains a supported
release).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: index-only scans
Next
From: Robert Haas
Date:
Subject: Re: index-only scans