Re: Postgresql 8.4.1 segfault, backtrace

From: "Michael Brown" <mbrown(at)fensystems(dot)co(dot)uk>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <mbrown(at)fensystems(dot)co(dot)uk>, <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:33:18
Message-ID: 58094.80.45.122.169.1253835198.squirrel@www.fensystems.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tom Lane said:
> I shall go and do some further investigation, but at least it's now
> clear where to look. Thanks for the report, and for being so helpful in
> providing information!

Thank you!

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;

immediately before

/* check for correct magic number (compatible version) */
if (fread(&magic, 1, sizeof(magic), fp) != sizeof(magic))
goto read_failed;
if (magic != RELCACHE_INIT_FILEMAGIC)
goto read_failed;

in load_relcache_init_file(). This, I hope, will cause postgres to always
invalidate and rebuild the relcache init file. The workaround has been in
place for around an hour so far and does not seem to be significantly
impacting upon performance. If there is anything dangerous about this
workaround, could you let me know?

If you come up with a patch against 8.4.1, we should be able to test it
under production loads almost straight away.

Thanks again,

Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Seneca Cunningham 2009-09-24 23:46:14 BUG #5080: test tablespace failure
Previous Message Tom Lane 2009-09-24 23:00:54 Re: Postgresql 8.4.1 segfault, backtrace