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: 5310.1166640954@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

Responses

Browse pgsql-hackers by date

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