Re: Rare corruption of pg_class index

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rare corruption of pg_class index
Дата
Msg-id 5310.1166640954@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rare corruption of pg_class index  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Rare corruption of pg_class index
Следующее
От: David Fetter
Дата:
Сообщение: Re: Release 8.2.0 done, 8.3 development starts