Re: Cache lookup failed for relation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Cache lookup failed for relation
Дата
Msg-id 23027.1360603233@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Cache lookup failed for relation  (David Clymer <david.clymer@vistashare.com>)
Ответы Re: Cache lookup failed for relation  (Péter Kovács <peter.dunay.kovacs@gmail.com>)
Re: Cache lookup failed for relation  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: Cache lookup failed for relation  (David Clymer <david.clymer@vistashare.com>)
Список pgsql-general
David Clymer <david.clymer@vistashare.com> writes:
> I've been seeing the following error in one database of ours:
>   "cache lookup failed for relation 7640518"

Always the same OID, or does it change?

> The SQL that apparently triggers this is:
>    drop table if exists ns_e5461ae570429d0b7863cce9ef4d4ead;

> Unfortunately, manual attempts to reproduce the issue have failed. In
> normal operation, this statement is run as one of several parallel queries,
> and the tables are by nature, short lived. That said, they are not
> temporary tables.

Hm ... what are the parallel queries exactly?  If you're doing something
like dropping both ends of a foreign-key linkage in parallel, I'd not be
very astonished by an error like this, especially not in 9.0.x.  It'd be
basically a race condition between two sessions both locking the same
table, but by the time the second one gets the lock, the first one has
dropped the table.  (Robert Haas has done some great work towards
eliminating this type of race condition lately, but it's sure not in
9.0.x.)

> One other item of note: db #2 has recently had an OID wrap-around, which
> makes me suspect that plays some part in this behavior.

I don't believe that theory at all.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: David Clymer
Дата:
Сообщение: Cache lookup failed for relation
Следующее
От: Péter Kovács
Дата:
Сообщение: Re: Cache lookup failed for relation