Re: [HACKERS] Unportable implementation of background worker start

> 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

Re: [HACKERS] OpenSSL 1.1 breaks configure and more

> 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

[HACKERS] isolation test deadlocking on buildfarm member coypu

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 buildfarm member failure on isolationCheck tests

=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

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

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] pika failing since the per-column collation patch

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

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

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

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

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] NaN/Inf fix for ECPG

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

. 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] NaN/Inf fix for ECPG

. 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

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

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] Pika buildfarm member failure on pgcrypto/test sha2

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

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

(#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

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

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] Regression failure on pika caused by CLUSTER rewrite

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

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

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

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

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] osprey buildfarm member has been failing for a long while

that. Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature

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

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

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

. 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

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] buildfarm NetBSD/m68k tsearch regression failure

/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

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] Regression (semi)fix for netbsd-mac68k

(__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] Port report: NetBSD 2.0 mac68k

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

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

=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

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

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

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] Port report: NetBSD 2.0 mac68k

- 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