From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Sven Suursoho <sven(at)spam(dot)pri(dot)ee> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: plpython improvements |
Date: | 2006-05-07 12:58:49 |
Message-ID: | 200605071258.k47Cwnl07303@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Sven Suursoho wrote:
> Sat, 06 May 2006 20:38:48 +0300, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>:
>
> > I still do not know why we can't do some kind of runtime test in python
> > and disable this feature for 2.4 builds that have debugging enabled.
> > Can we do a dynamic function load test from plpython? There must be
> > some function that is only visible in debug builds.
>
> Yes, I already did research last week after discussions about that. In
> unmodified Python distribution, in configure:
> if --with-pydebug
> define Py_DEBUG
> undef NDEBUG
> else
> undef Py_DEBUG
> define NDEBUG
> fi
>
> Unfortunately, this is not case for Fedora Core 4, where assertions are
> used unconditionally. And to make things worse, there is no runtime symbol
> at all to indicate whether Python is compiled with debugging/assertions
> enabled (Py_DEBUG & NDEBUG are preprocessor symbols)
Can you test dynamically loading a function that is only visible in the
symbol table of debug builds, and check the return code?
In the Fedora Core 4 case, how did they make assertions always enabled?
I see the fix:
http://mail.python.org/pipermail/python-checkins/2005-August/046571.html
How did Fedora Core 4 enable asserts? I see the patch calling libc's
assert() directly, which should be enabled all the time.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-05-07 13:09:17 | Re: pgstat: delayed write of stats file |
Previous Message | Sven Suursoho | 2006-05-07 09:42:57 | Re: plpython improvements |