On Thu, Nov 14, 2002 at 09:06:01AM -0500, Tom Lane wrote:
> "Magnus Naeslund(f)" <mag@fbab.net> 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 forPostgreSQL 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-zerosgeometry/i.86-.*-openbsd=geometry-positive-zerosgeometry/sparc-.*-openbsd=geometry-positive-zeros
-geometry/.*-netbsd=geometry-positive-zerosgeometry/hppa.*-hpux9=geometry-positive-zerosgeometry/hppa.*-hpux10=geometry-positive-zerosgeometry/.*-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
