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

Re: Rare corruption of pg_class index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Greg Sabino Mullane <greg(at)turnstep(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rare corruption of pg_class index
Date: 2006-12-20 18:55:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Greg Sabino Mullane wrote:
>> I'm encountering some disconcerting problems on a 8.1.3 database.
>> Very occasionally, I get a "could not open relation with OID xxx".

Does the mentioned OID actually correspond to the OID of the table it's
supposed to be opening, or is it wrong?  Is anything being done to
the table schema in parallel?

If the table is occasionally dropped and recreated, there's a known race
condition that could cause it: we lookup the table name in pg_class to
get the OID, then lock the relation by OID, then try to finish opening
the relation.  By the time we obtain lock the original rel could be gone
and the name now refers to some other OID, but we'll fail because the
old OID is no longer anywhere to be found.  I think this is fixed in 8.2.

If the table is perfectly static then another explanation is needed ...

> It would help if you could get a stack trace at the moment of the
> problem, but I'm not sure how to do that.

Perhaps insert an abort() call right before the elog(ERROR)
that's reporting this.  (I think there are three possibilities,
but they're all in heapam.c so you might as well just hack them all.)

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: David FetterDate: 2006-12-20 19:01:32
Subject: Re: Release 8.2.0 done, 8.3 development starts
Previous:From: Chris BrowneDate: 2006-12-20 18:38:26
Subject: Re: Release 8.2.0 done, 8.3 development starts

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