From: | Seneca Cunningham <tentra(at)gmail(dot)com> |
---|---|
To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Recent SIGSEGV failures in buildfarm HEAD |
Date: | 2006-12-31 17:48:38 |
Message-ID: | 20061231174838.GJ2872@herodotus.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Sun, Dec 31, 2006 at 05:43:45PM +0100, Stefan Kaltenbrunner wrote:
> Tom Lane wrote:
> > What you seem to have here is infinite recursion during relcache
> > initialization. That's surely not hard to believe, considering I just
> > whacked that code around, and indeed changed some of the tests that are
> > intended to prevent such recursion. But what I don't understand is why
> > it'd be platform-specific, much less not perfectly repeatable on the
> > platforms where it does manifest. Anyone have a clue?
>
> fwiw - I can trigger that issue now pretty reliably on a fast Opteron
> box (running Debian Sarge/AMD64) with make regress in a loop - I seem to
> be able to trigger it in about 20-25% of the runs.
> the resulting core however looks totally stack corrupted and not really
> usable :-(
By reducing the stack size on jackal from the default of 8MB to 3MB, I
can get this to trigger in roughly 30% of the runs while preserving the
passed tests in the other parallel groups.
--
Seneca
tentra(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2006-12-31 20:05:30 | access method's algorithm authors |
Previous Message | Tom Lane | 2006-12-31 17:41:48 | Re: Recent SIGSEGV failures in buildfarm HEAD |
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Morgan Lloyd | 2007-01-01 21:50:18 | Re: BCC55 and libpq 8.2 |
Previous Message | Tom Lane | 2006-12-31 17:41:48 | Re: Recent SIGSEGV failures in buildfarm HEAD |