Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-31 Thread Andres Freund
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Tom Lane
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Noah Misch
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Andres Freund
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Tom Lane
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Noah Misch
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Noah Misch
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Tom Lane
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Andres Freund
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Tom Lane
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Peter Eisentraut
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Andres Freund
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Peter Geoghegan
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Tom Lane
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Andres Freund
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Andrew Dunstan
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread didier
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Andres Freund
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Tom Lane
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.

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Robert Haas
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

Re: [HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Tom Lane
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

[HACKERS] OSX doesn't accept identical source/target for strcpy() anymore

2013-10-28 Thread Andres Freund
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