From: Lamar Owen <lamar.owen@wgcr.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tim Brookes <tim.brookes@mcmail.com>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: libpq++ tracing considered harmful (was Re: libpq++ memory problems)
Date: Thu, 20 Apr 2000 14:06:19 -0400
Message-ID: <38FF471B.4463ECF2@wgcr.org> (raw)
References: <38FB6FA1.C63B030B@mcmail.com>
<16483.956019092@sss.pgh.pa.us>
<38FEB8DB.DBC3460E@mcmail.com>
<2182.956243193@sss.pgh.pa.us>
<38FF2126.9525DB82@mcmail.com>
<38FF243E.E5C0E87E@wgcr.org>
<8163.956252492@sss.pgh.pa.us>
Tom Lane wrote:
> Ah-hah, figured it out. There *was* a recent relevant change, but the
> log message for it didn't say anything about leaks. The problem is
> in the "debug" code for PgConnection, which in 6.5.* looks like:
[snip]
> 1. "DEBUG" is a symbol defined in the backend header files (it's a
> severity level constant for elog()). So although libpq++'s Makefile
> thinks it can turn the code on or off via -DDEBUG, it's mistaken;
> that debug-tracing code always gets compiled.
> Oliver Elphick fixed that a month or so ago by changing the
> controlling symbol to "DEBUGFILE". So that's why you see the leak
> in 6.5.3 and I don't see it in current sources.
> 4. If any tracing did occur, all of the output from (perhaps many)
> different PgConnection objects in different program runs would all
> get dumped into the same temp file, leaving it of doubtful use to
> anybody.
> 5. One could reasonably doubt that it's a good idea to have a compiled-in
> option to dump the entire trace of a program's interaction with the
> backend into a publicly readable temp file. Can you say "security
> hole"? Seems to me that this function should require a specific
Hmmmm..
> request from the application, not be something that could accidentally
> get installed as the default behavior of a system library. (Think
> what would happen if RPMs containing such behavior got distributed...)
Yes, think of it. How many other such 'surprises' lurk, I wonder?
> Perhaps something can be salvaged from the wreckage, but for now the
> right answer is just to make sure that this code is not compiled.
And to compile this code you supply _which_ configure option? Which is
the default (which is how the RPMset is built)? Or is this like one of
the many options in config.h.in (or config.h, depending on which side of
the configure divide you prefer to edit....), like so many other options
that aren't configure'able?
This is as good an argument as any for a single, canonical, RPMset as
I've seen in a while, Tom. I (and others in the development group who
can help watchdog the RPMset) just have to be extra-diligent to make
sure stuff like compiling this freakish code doesn't happen.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: lamar.owen@wgcr.org, tgl@sss.pgh.pa.us, tim.brookes@mcmail.com
Subject: Re: libpq++ tracing considered harmful (was Re: libpq++ memory problems)
In-Reply-To: <38FF471B.4463ECF2@wgcr.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox