Re: Rare corruption of pg_class index - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rare corruption of pg_class index
Date
Msg-id 5310.1166640954@sss.pgh.pa.us
Whole thread Raw
In response to Re: Rare corruption of pg_class index  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Rare corruption of pg_class index  ("Greg Sabino Mullane" <greg@turnstep.com>)
Re: Rare corruption of pg_class index  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Rare corruption of pg_class index
Next
From: David Fetter
Date:
Subject: Re: Release 8.2.0 done, 8.3 development starts