[HACKERS] Buildfarm's opsrey goes green...

2005-07-30 Thread Rémi Zara
not, hence the crash in the tests. NetBSD 2.0 does not have all the necessary threadsafe calls to pass the thread safety test made during configure. Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature

[HACKERS] Port report: NetBSD 2.0 mac68k

2004-12-14 Thread Rémi Zara
- PostgreSQL 8.0.0rc1 on m68k-unknown-netbsdelf2.0, compiled by GCC gcc (GCC) 3.3.3 (NetBSD nb3 20040520) (1 row) in make check, two tests fail: float8 and misc. I've attached the regression.diffs file. Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net

Re: [HACKERS] Port report: NetBSD 2.0 mac68k

2004-12-20 Thread Rémi Zara
getpwuid() which is not thread-safe. ** Your system has getaddrinfo(); it does not need gethostbyname() or gethostbyname_r(). ** YOUR PLATFORM IS NOT THREAD-SAFE. ** Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature

[HACKERS] Regression (semi)fix for netbsd-mac68k

2004-12-22 Thread Rémi Zara
=float8-small-is-zero float8/.*-qnx=float8-exp-three-digits float8/i.86-pc-mingw32=float8-exp-three-digits-win32 float8/i.86-pc-cygwin=float8-small-is-zero Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] Regression (semi)fix for netbsd-mac68k

2004-12-22 Thread Rémi Zara
they will have this behavior on all hardware not just Intel. From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the problem (it's not part of resultmap, and passes the float8 test). Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic

Re: [HACKERS] Regression (semi)fix for netbsd-mac68k

2004-12-22 Thread Rémi Zara
on all hardware not just Intel. From pgbuildfarm, it seems that openBSD sparc64 does not exhibit the problem (it's not part of resultmap, and passes the float8 test). OK, never mind that then. Patch applied as-is. Cool, thanks ! Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s

Re: [HACKERS] Port report: NetBSD 2.0 mac68k

2004-12-24 Thread Rémi Zara
Le 21 déc. 04, à 06:45, Bruce Momjian a écrit : Rémi Zara wrote: Le 16 d?c. 04, ? 22:48, Bruce Momjian a ?crit : I am confused by the threading failure. I don't see any free() call in thread_test.c. Would you go to the tools/thread directory and run the program manually and use a debugger

Re: [HACKERS] Regression (semi)fix for netbsd-mac68k

2004-12-25 Thread Rémi Zara
(__mc68000__) || (defined(__m68k__))) defined(__ELF__) typedef int32 ((*func_ptr) ()); #else Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure

2004-12-29 Thread Rémi Zara
/DA9628 LOG: record with zero length at 0/E09988 LOG: redo done at 0/E09958 LOG: database system is ready The cube contrib regression tests passes with this setup. I'm trying right now to gmake installcheck in contrib/, to see if there are dependancies between tests. Regards, Rémi Zara -- Rémi Zara

Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure

2004-12-29 Thread Rémi Zara
0x000e465e in main (argc=3, argv=0xc674) at main.c:268 Regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure

2004-12-30 Thread Rémi Zara
. The tsearch test passes when compiled with -O0 (postgres is still compiled with -O2) regards, Rémi Zara -- Rémi Zara http://www.remi-zara.net/ smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] buildfarm NetBSD/m68k tsearch regression failure

2004-12-30 Thread Rémi Zara
with -O2, the pushval_morph func address is 0x0 (in query.c). It goes away with the following patch, which might not be a proper solution Regards, Rémi Zara Index: query.c === RCS file: /projects/cvsroot/pgsql/contrib/tsearch

Re: [HACKERS] osprey buildfarm member has been failing for a long while

2006-05-28 Thread Rémi Zara
that. Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] osprey buildfarm member has been failing for a long while

2006-05-29 Thread Rémi Zara
would be the most likely culprit if this is a ulimit thing. Changing this limit and removing ccache made the trick. Next run will try and re-enable ccache (this build lasted nearly 11.5 hours :-) Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature

Re: [HACKERS] Regression failure on pika caused by CLUSTER rewrite

2010-02-15 Thread Rémi Zara
connectivity issues then and is only now building current HEAD again. Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Pika buildfarm member failure on pgcrypto/test sha2

2010-02-23 Thread Rémi Zara
Anything I should try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Pika buildfarm member failure on pgcrypto/test sha2

2010-02-24 Thread Rémi Zara
Le 24 févr. 2010 à 01:04, Marko Kreen a écrit : On 2/24/10, Rémi Zara remi_z...@mac.com wrote: Pika, which has been upgraded to NetBSD/mips 5.0.2, failed twice in a row pgcrypto/test sha2 because of the following warning (identical each time) : Anything I should try ? Please try

Re: [HACKERS] NaN/Inf fix for ECPG

2010-02-24 Thread Rémi Zara
to NetBSD 5.0.2, and the problem is still there. There are some tests (in core) which tests for NaN and Infinity, which pass. So either those tests are insufficient, or the code does something different there. Anything you want me to try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list

Re: [HACKERS] NaN/Inf fix for ECPG

2010-02-24 Thread Rémi Zara
(#ifdef __NetBSD__ __mips__), isnan(NAN) is true, isnan((double)NAN) is false, and isnan((double)(0.0 / 0.0)) is true. Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] NaN/Inf fix for ECPG

2010-02-25 Thread Rémi Zara
to confirm the above? bash-4.1$ gcc -Wall -o nantest1 nantest1.c -lm bash-4.1$ ./nantest1 computed NAN 1 0 defined INFINITY 0 1 Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref

Re: [HACKERS] NaN/Inf fix for ECPG

2010-02-25 Thread Rémi Zara
to NetBSD 5.0.2, and the problem is still there. There are some tests (in core) which tests for NaN and Infinity, which pass. So either those tests are insufficient, or the code does something different there. Anything you want me to try ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing

Re: [HACKERS] NaN/Inf fix for ECPG

2010-02-26 Thread Rémi Zara
. The fact is that the code is not used in the backend, because strtod(NaN, endptr) works. (isnan(strtod(NaN, endptr)) is true). I should also note that isnan((double)nan()) is true (works). I will also report to NetBSD that isnan((double)NAN) does not work on mips. Regards, Rémi Zara

Re: [HACKERS] NaN/Inf fix for ECPG

2010-02-27 Thread Rémi Zara
to the regression tests. So what's the best way to workaround the bug in NetBSD/mips ? (nan(), (0.0/0.0), strtod(nan, null) ?) Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] NaN/Inf fix for ECPG

2010-02-27 Thread Rémi Zara
. So what's the best way to workaround the bug in NetBSD/mips ? I don't think it's our bug to fix. It would mean retiring pika until/if the bug is fixed... :-( Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription

Re: [HACKERS] Why is osprey dumping core in REL8_2 branch?

2007-03-11 Thread Rémi Zara
originally enabled this conf because pg would not otherwise BUILD... Doesn't this mean that there is some place where the return value of malloc is not checked for null ? Regards, Rémi Zara Le 11 mars 07 à 08:32, Tom Lane a écrit : I wrote: =?ISO-8859-1?Q?R=E9mi_Zara?= [EMAIL PROTECTED

[HACKERS] pika buildfarm member failure on isolationCheck tests

2011-06-18 Thread Rémi Zara
=2011-06-17%2015%3A45%3A30 It seems that for this stage, the server log (which contains the failed assertion) is not sent back to the buildfarm server. Maybe that should be fixed ? Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature

[HACKERS] isolation test deadlocking on buildfarm member coypu

2011-07-16 Thread Rémi Zara
into action. See http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=coypudt=2011-07-16%2011%3A30%3A02 for the logs Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature

[HACKERS] pika failing since the per-column collation patch

2011-02-12 Thread Rémi Zara
this ? Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] pika failing since the per-column collation patch

2011-02-14 Thread Rémi Zara
Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit : On lör, 2011-02-12 at 13:34 +0100, Rémi Zara wrote: Since the per-column collation patch went in, pika (NetBSD 5.1/mips) started failing consistently with this diff: *** /home/pgbuildfarm/workdir/HEAD/pgsql.15101/src/test/regress

Re: [HACKERS] pika failing since the per-column collation patch

2011-02-16 Thread Rémi Zara
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit : Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit : It's only failing on this one machine, but there isn't anything platform-specific in this code, so I'd look for memory management faults on the code or a compiler problem. Try with lower

Re: [HACKERS] pika failing since the per-column collation patch

2011-02-17 Thread Rémi Zara
Le 14 févr. 2011 à 19:27, Rémi Zara a écrit : Le 12 févr. 2011 à 18:51, Peter Eisentraut a écrit : It's only failing on this one machine, but there isn't anything platform-specific in this code, so I'd look for memory management faults on the code or a compiler problem. Try with lower

Re: [HACKERS] pika failing since the per-column collation patch

2011-02-27 Thread Rémi Zara
in varstr_cmp: WARNING: Comparing B011 and fetch first clause in subqueries^?^?\xa0 ERROR: locale operation to be invoked, but no collation was derived STATEMENT: select max(histogram_bounds) from pg_stats; Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

2016-08-29 Thread Rémi Zara
> Le 29 août 2016 à 19:46, Heikki Linnakangas a écrit : > > > Tom, Rémi, can you fix locust and prairiedog, please, by updating OpenSSL or > removing --with-openssl? > Hi, Should be OK for locust on next build. Rémi -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Unportable implementation of background worker start

2017-04-24 Thread Rémi Zara
> Le 25 avr. 2017 à 01:47, Tom Lane a écrit : > > I wrote: >> What I'm inclined to do is to revert the pselect change but not the other, >> to see if that fixes these two animals. If it does, we could look into >> blacklisting these particular platforms when choosing