| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: numeric test on RiscPC |
| Date: | 2002-04-08 14:18:23 |
| Message-ID: | 20479.1018275503@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Patrick Welche <prlw1(at)newn(dot)cam(dot)ac(dot)uk> writes:
> I have just found to my surprise:
> ============== running regression test queries ==============
> parallel group (13 tests): char name int2 text float4 oid int4 varchar int8 float8 boolean bit numeric
> PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
> 27747 prlw1 72 4 596K 276K RUN 277.7H 98.10% 98.10% sh
> 277.7H being just over 11.5 days!
> Have any of you tried
> PostgreSQL 7.2 on acorn32-unknown-netbsd1.5ZB, compiled by GCC egcs-1.1.2
> on an Acorn RiscPC with a SA-110? (This is the well known "halting problem" :) )
Looks like Acorn's shell has the same bug documented to exist in HPUX's
shell (see doc/FAQ_HPUX :-() ... it gets confused when it has to manage
more than about a dozen child processes.
On HPUX I can work around this by telling pg_regress to use ksh instead.
If you have any other shells besides plain sh, give them a try.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephane Bortzmeyer | 2002-04-08 14:19:02 | Re: Seq. scan when using comparison operators, why? [netaktiv.com #150] |
| Previous Message | Tom Lane | 2002-04-08 14:15:05 | Re: Seq. scan when using comparison operators, why? [netaktiv.com #150] |