On 2013-10-29 02:29:03 +0100, Andres Freund wrote:
> 3. valgrind gets floating point computations for
> exp(larger_negative_double) wrong and returns the wrong error message:
>
> regression=# SELECT exp(-808.3::float8);
> ERROR: value out of range: overflow
>
> exp sets errno=ERANGE and returns
Andres Freund writes:
> On 2013-10-28 21:14:48 -0400, Tom Lane wrote:
>> 2. valgrind causes autovacuum to dump core, at least on my box (RHEL6).
> Yea, I know which bug that is, I've pushed the valgrind guys into fixing
> it...
> https://bugs.kde.org/show_bug.cgi?id=280114
Thanks, I whined to Re
On Mon, Oct 28, 2013 at 10:30:10PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Oct 28, 2013 at 09:14:48PM -0400, Tom Lane wrote:
> >> 2. valgrind causes autovacuum to dump core, at least on my box (RHEL6).
>
> > Don't bother with versions older than Valgrind 3.8.1.
>
> $ rpm -qa | gr
On 2013-10-28 22:20:02 -0400, Noah Misch wrote:
> > 2. valgrind causes autovacuum to dump core, at least on my box (RHEL6).
>
> Don't bother with versions older than Valgrind 3.8.1. Besides having a fix
> for that bug, it runs PostgreSQL an order of magnitude faster, per the comment
> in pg_confi
Noah Misch writes:
> On Mon, Oct 28, 2013 at 09:14:48PM -0400, Tom Lane wrote:
>> 2. valgrind causes autovacuum to dump core, at least on my box (RHEL6).
> Don't bother with versions older than Valgrind 3.8.1.
$ rpm -qa | grep valgrind
valgrind-3.8.1-3.2.el6.x86_64
regar
On Mon, Oct 28, 2013 at 04:02:36PM -0400, Tom Lane wrote:
> It seems to me the most reasonable fix for this is to make
> TupleDescInitEntry notice that the passed "attributeName" points
> at the tupdesc's name field and not call namestrcpy if so.
+1
--
Noah Misch
EnterpriseDB
On Mon, Oct 28, 2013 at 09:14:48PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-10-28 16:02:36 -0400, Tom Lane wrote:
> >> The larger problem though is what you'd do with the output. There's
> >> enough false-positive noise from valgrind that I can't see having
> >> the buildfarm ru
Andres Freund writes:
> On 2013-10-28 21:14:48 -0400, Tom Lane wrote:
>> They're not all gone according to my testing; but there are far worse
>> problems:
> Spurious or real bugs? Inside PG or libc?
I saw a bunch of uninitialized-value complaints in initdb, apparently from
places in BootstrapXL
On 2013-10-28 21:14:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2013-10-28 16:02:36 -0400, Tom Lane wrote:
> >> The larger problem though is what you'd do with the output. There's
> >> enough false-positive noise from valgrind that I can't see having
> >> the buildfarm run just fail
Andres Freund writes:
> On 2013-10-28 16:02:36 -0400, Tom Lane wrote:
>> The larger problem though is what you'd do with the output. There's
>> enough false-positive noise from valgrind that I can't see having
>> the buildfarm run just fail if there are any messages. What to do
>> instead isn't
On 10/28/13, 4:11 PM, Peter Geoghegan wrote:
> On Mon, Oct 28, 2013 at 6:11 PM, Tom Lane wrote:
>> Both gcc and glibc have been moving steadily in the direction of
>> aggressively exploiting "undefined behavior" cases for optimization
>> purposes. I don't know if there is yet a platform where str
On 2013-10-28 16:02:36 -0400, Tom Lane wrote:
> Andres Freund writes:
> > It'd be relatively easy to add support for make check (not installcheck)
> > wrapping postgres in valgrind via pg_regress, but I am not sure that's
> > the best way to go.
>
> > I think defining an additional CFLAG (USE_VAL
On Mon, Oct 28, 2013 at 6:11 PM, Tom Lane wrote:
> Both gcc and glibc have been moving steadily in the direction of
> aggressively exploiting "undefined behavior" cases for optimization
> purposes. I don't know if there is yet a platform where strncpy with
> src == dest behaves oddly, but we'd be
Andres Freund writes:
> It'd be relatively easy to add support for make check (not installcheck)
> wrapping postgres in valgrind via pg_regress, but I am not sure that's
> the best way to go.
> I think defining an additional CFLAG (USE_VALGRIND) shouldn't be a
> problem?
CFLAGS doesn't seem to h
On 2013-10-28 15:20:20 -0400, Andrew Dunstan wrote:
>
> On 10/28/2013 02:26 PM, Andres Freund wrote:
> >
> >It'd be neat if we could get a buildfarm animal up that uses valgrind -
> >which would catch such and lots of other errors. That's where the topic
> >has come up in the past:
> >http://www.p
On 10/28/2013 02:26 PM, Andres Freund wrote:
It'd be neat if we could get a buildfarm animal up that uses valgrind -
which would catch such and lots of other errors. That's where the topic
has come up in the past:
http://www.postgresql.org/message-id/20110312133224.GA7833%40tornado.gateway.2wir
Hi,
On Mon, Oct 28, 2013 at 7:11 PM, Tom Lane wrote:
>
> If copying takes place between objects that overlap, the behavior is
> undefined.
>
> Both gcc and glibc have been moving steadily in the direction of
> aggressively exploiting "undefined behavior" cases for optimization
> purposes. I do
On 2013-10-28 14:11:12 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Mon, Oct 28, 2013 at 12:11 PM, Andres Freund
> > wrote:
> >> There have been previous discussions about fixing strcpy calls with
> >> identical source/destination (same for memcpy) but it was deemed not
> >> worth the eff
Robert Haas writes:
> On Mon, Oct 28, 2013 at 12:11 PM, Andres Freund
> wrote:
>> There have been previous discussions about fixing strcpy calls with
>> identical source/destination (same for memcpy) but it was deemed not
>> worth the effort. I don't really see an alternative to fixing it now.
On Mon, Oct 28, 2013 at 12:11 PM, Andres Freund wrote:
> Hi,
>
> On -bugs it was reported that initdb of 9.3 failed with a
> assertion.
>
> On 2013-10-28 16:52:13 +0100, Matthias Schmitt wrote:
>> > In that case, could you enable coredumps and get a backtrace from that
>> > coredump? I unfortunate
Andres Freund writes:
> There have been previous discussions about fixing strcpy calls with
> identical source/destination (same for memcpy) but it was deemed not
> worth the effort. I don't really see an alternative to fixing it now.
I'm not seeing this with bare-bones
./configure --enable
Hi,
On -bugs it was reported that initdb of 9.3 failed with a
assertion.
On 2013-10-28 16:52:13 +0100, Matthias Schmitt wrote:
> > In that case, could you enable coredumps and get a backtrace from that
> > coredump? I unfortunately have zero clue about OSX, so I can't really
> > help you with tha
22 matches
Mail list logo