Re: "could not open relation with OID" errors after promoting the standby to master

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Joachim Wieland <joe(at)mcknight(dot)de>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "could not open relation with OID" errors after promoting the standby to master
Date: 2012-05-17 03:38:04
Message-ID: 1337225608-sup-3384@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Excerpts from Joachim Wieland's message of mar may 15 22:37:15 -0400 2012:
> I've switched servers yesterday night and the previous slave is now
> the master. This is 9.0.6 (originally) / 9.0.7 (now) on Linux.
>
> Now I'm seeing a bunch of
>
> ERROR: could not open relation with OID 1990987633

> #7 0x00000000004b6e90 in RemoveTempRelations () at namespace.c:3234
> #8 InitTempTableNamespace () at namespace.c:3066

> Any idea? It looks suspicious that it calls into RemoveTempRelations()
> from InitTempNamespace() thereby removing the table it is about to
> create?

Well, that is not surprising in itself -- InitTempTableNamespace calls
RemoveTempRelations to cleanup from a possibly crashed previous backend
with the same ID. So that part of the backtrace looks normal to me
(unless there is something weird going on, which might very well be the
case).

It looks to me like you might have leftover pg_depend entries without
the corresponding entries in other catalogs (pg_class, etc). No idea
how that might happen, but maybe it's a starting point to investigate.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-17 03:43:13 counting pallocs
Previous Message Joshua Berkus 2012-05-17 03:08:23 Why is indexonlyscan so darned slow?