From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: weird buildfarm failures on arm/mipsel and --with-tcl |
Date: | 2007-01-09 02:52:06 |
Message-ID: | 19337.1168311126@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> one of my new buildfarm boxes (an Debian/Etch based ARM box) is
> sometimes failing to stop the database during the regression tests:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=quagga&dt=2007-01-08%2003:03:03
> this only seems to happen sometimes and only if --with-tcl is enabled on
> quagga.
> lionfish (my mipsel box) is able to trigger that on every build if I
> enable --with-tcl but it is nearly impossible to debug it there because
> of the low amount of memory and diskspace it has.
Hm, could pl/tcl somehow be preventing the backend from exiting once
it's run any pl/tcl stuff? I have no idea why though, and even less
why it wouldn't be repeatable.
> After the stopdb failure we still have those processes running:
> pgbuild 3488 0.0 2.4 43640 6300 ? Ss 06:15 0:01
> postgres: pgbuild pl_regression [local] idle
Can you get a stack trace from this process?
> pgbuild 3489 0.0 0.0 0 0 ? Z 06:15 0:00
> [postgres] <defunct>
This is a bit odd ... if that process is a direct child of the
postmaster it should have been reaped promptly. Could it be a child
of the other backend? If so, why was it started? Please try the
ps again with whatever switch it needs to list parent process ID.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gurjeet Singh | 2007-01-09 02:53:45 | Re: [PATCHES] [Fwd: Index Advisor] |
Previous Message | Jeremy Drake | 2007-01-09 02:49:55 | pltcl regression failures with ORDER BY ... USING change |