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
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 |