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