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 pselect. > > It looks like

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 (pgsql-hackers@postgresql.org)

[HACKERS] isolation test deadlocking on buildfarm member coypu

dfarm isolationtest [local] idle in transaction). Again, the buildfarm perlscript kicked into action. See http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=coypu&dt=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

org/cgi-bin/show_log.pl?nm=pika&dt=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

; > It'd be helpful if you could identify the specific values that are > getting compared at the moment of the failure. > Hi, Here is what I get after adding an elog in varstr_cmp: WARNING: Comparing "B011 " and " in subqueries^?^?\xa0" ERROR: local

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

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

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/

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

igate 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

if it doesn't". I'm not > sure whether full IEEE float support has gotten sufficiently universal > to justify expecting more. I guess we could try it and see how many > other buildfarm members fail. > >> So what's the best way to workaround the bug in NetBSD/mips

Re: [HACKERS] NaN/Inf fix for ECPG

- Infinity (1 row) So it is indeed the same behavior. Maybe that should be added 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

Re: [HACKERS] NaN/Inf fix for ECPG

lso report to NetBSD that isnan((double)NAN) does not work on mips. 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

ade. I upgraded pika 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 Zar

Re: [HACKERS] NaN/Inf fix for ECPG

explicit about that the (0.0/0.0) division > produces NaN. How about doing it explicitely in ECPG? > > Rémi: please, run this code 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 --

Re: [HACKERS] NaN/Inf fix for ECPG

o nantest nantest.c -lm -bash-4.1$ ./nantest defined NAN 0 1 defined INFINITY 0 1 Ok. So, on NetBSD/mips (#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-hack

Re: [HACKERS] NaN/Inf fix for ECPG

aded pika 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

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 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 t

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

--- 3d208973ab3508dbbd7e2c2862ba290ad3010e4978c198dc4d8fd014e582823a89e16f9b2a7bbc1ac938e2d199e8bea4 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

some 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?

I had 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?= <[EM

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

egment size 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

the CC => "cache gcc" line in the config file. I'll try that. Regards, Rémi Zara smime.p7s Description: S/MIME cryptographic signature

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

, 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] NetBSD mac68k crashing on union regression test

Le 12 avr. 05, à 08:23, Rémi Zara a écrit : Hi, With the following patch, the crash still occurs in the same way. But it does seem, reading the code, that it still may be necessary. Well, I've re-run the checks several times after a clean make and it does not crash anymore. So the patch see

Re: [HACKERS] NetBSD mac68k crashing on union regression test

ounts */ + if ((*p == '%') || (*p == '*')) /* counts %% as two, so overcounts */ percents++; /* Need to use malloc() because memory system might not be started yet. */ Regards, Rémi Zara Le 11 avr. 05, à 22:31, Tom Lane a écrit : =?ISO-8

[HACKERS] NetBSD mac68k crashing on union regression test

is odd (char 0). It should be one of 'eEfgG', no ? Regards, Rémi Zara #0 0x0446f192 in __bt_search () from /usr/lib/libc.so.12 #1 0x0446f6de in __bt_search () from /usr/lib/libc.so.12 #2 0x0447110e in __dtoa () from /usr/lib/libc.so.12 #3 0x0446d4c0 in vfprintf_unlocked () from /usr/li

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

at when compiled 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

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

becomes more accurate. 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

0 in PostmasterMain (argc=3, argv=0xc674) at postmaster.c:917 #22 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

ystem was not properly shut down; automatic recovery in progress LOG: redo starts at 0/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

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

*/ -#if defined(__mc68000__) && defined(__ELF__) +#if (defined(__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 debugg

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

ie, assume 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). OK, never mind that then. Patch applied as-is. Cool, thanks ! Regards, Rémi Zara -

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

the BSDen, ie, assume 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 De

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

m68k-.*-netbsd=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] Port report: NetBSD 2.0 mac68k

uses 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

version - 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