Re: Postgresql 8.4.1 segfault, backtrace - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Postgresql 8.4.1 segfault, backtrace
Date
Msg-id 1845.1253836663@sss.pgh.pa.us
Whole thread Raw
In response to Re: Postgresql 8.4.1 segfault, backtrace  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Postgresql 8.4.1 segfault, backtrace  ("Michael Brown" <mbrown@fensystems.co.uk>)
Re: Postgresql 8.4.1 segfault, backtrace  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
"Michael Brown" <mbrown@fensystems.co.uk> writes:
> I have put in place a temporary workaround on the production system, which
> is to insert a

>     // Pretend that the cache is always invalid
>     fprintf ( stderr, "*** bypassing cache ***\n" );
>     goto read_failed;

I don't think this will actually help --- if anything it exposes you
to the bug more :-(.  Given my current theory, there is not anything
wrong with the init file.  The problem is a sort of race condition
that would be triggered by very high cache-inval traffic during startup
of a new backend.  I looked at the cache inval array in your coredump,
and it looked like there had been a whole bunch of table deletions
happening concurrently with the startup --- "whole bunch" meaning
hundreds if not thousands.  Is there anything in your application
behavior that might encourage a lot of table drops to happen
concurrently?

I'll get you a real fix as soon as I can, but might not be till
tomorrow.

            regards, tom lane

pgsql-bugs by date:

Previous
From: "Seneca Cunningham"
Date:
Subject: BUG #5080: test tablespace failure
Next
From: Tom Lane
Date:
Subject: Re: BUG #5080: test tablespace failure