On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote: > "Magnus Naeslund(f)" <[EMAIL PROTECTED]> writes: > > OK OK, before anyone rubs my nose in it, i see the fork() failures :) > > > I'll see what's causing the fork() problems... > > Too low processes-per-user limit, likely.
Success for PostgreSQL 7.4devel on acorn32-unknown-netbsd1.6K, compiled by GCC 2.95.3 In other words NetBSD/acorn32-1.6K. The fork() problem for me was not enough memory, but checking with --schedule=./serial_schedule made it pass all the tests, except geometry, which leads me to change my mind and suggest: Index: resultmap =================================================================== RCS file: /projects/cvsroot/pgsql-server/src/test/regress/resultmap,v retrieving revision 1.59 diff -u -r1.59 resultmap --- resultmap 2002/11/12 20:02:32 1.59 +++ resultmap 2002/11/19 15:20:19 @@ -18,7 +18,6 @@ geometry/alpha.*-freebsd4.[0-5]=geometry-positive-zeros geometry/i.86-.*-openbsd=geometry-positive-zeros geometry/sparc-.*-openbsd=geometry-positive-zeros -geometry/.*-netbsd=geometry-positive-zeros geometry/hppa.*-hpux9=geometry-positive-zeros geometry/hppa.*-hpux10=geometry-positive-zeros geometry/.*-irix6=geometry-positive-zeros as this acorn32 is running on a StrongARM processor, so has nothing to do with libm387. Maybe get rid of the geometry-positive-zeros and see if someone complains and tells me otherwise? Cheers, Patrick ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
