Skip site navigation (1) Skip section navigation (2)

Re: Postgresql 8.4.1 segfault, backtrace

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Michael Brown" <mbrown(at)fensystems(dot)co(dot)uk>
Cc: rn214(at)hermes(dot)cam(dot)ac(dot)uk, pgsql-bugs(at)postgreSQL(dot)org
Subject: Re: Postgresql 8.4.1 segfault, backtrace
Date: 2009-09-24 23:57:43
Message-ID: 1845.1253836663@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Michael Brown" <mbrown(at)fensystems(dot)co(dot)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

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-09-25 00:21:40
Subject: Re: BUG #5080: test tablespace failure
Previous:From: Seneca CunninghamDate: 2009-09-24 23:46:14
Subject: BUG #5080: test tablespace failure

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group