"could not open relation with OID" errors after promoting the standby to master - Mailing list pgsql-hackers

From Joachim Wieland
Subject "could not open relation with OID" errors after promoting the standby to master
Date
Msg-id CACw0+1385D3H6cAd2FqO5JxaMBPY8DWcEMptZfYp0UNuK14EjA@mail.gmail.com
Whole thread Raw
Responses Re: "could not open relation with OID" errors after promoting the standby to master
Re: "could not open relation with OID" errors after promoting the standby to master
List pgsql-hackers
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
STATEMENT:  create temp table seen_files (fileid integer)

Interestingly enough, 90% of these happen with "create temp table"
statements, but I also see them with regular read-only select
statements, but I'd say it's at most 10% of these.

Some reports for this error message suggested running reindex, so I've
run reindex table and also vacuum full on all system catalogs (just
for good measure) but that didn't help much. Restarting the cluster
didn't help either.

If it matters, I have not promoted the master with a trigger file but
restarted it after deleting recovery.conf.

Everything else appears to be running fine but since it's a) annoying
and b) not very comforting, I might dump and restore tomorrow night.

I added a sleep() after this error message so that I could attach a
debugger and grab a stack trace:

(gdb) bt
#0  0x0000003eb509a170 in __nanosleep_nocancel () from /lib64/libc.so.6
#1  0x0000003eb5099fc4 in sleep () from /lib64/libc.so.6
#2  0x000000000046375c in relation_open (relationId=1990987633,
lockmode=<value optimized out>) at heapam.c:906
#3  0x00000000004b26e6 in heap_drop_with_catalog (relid=1990987633) at
heap.c:1567
#4  0x00000000004ace01 in doDeletion (object=0x62dfbc8,
depRel=0x2b9ea756f6a8) at dependency.c:1046
#5  deleteOneObject (object=0x62dfbc8, depRel=0x2b9ea756f6a8) at
dependency.c:1004
#6  0x00000000004aeb00 in deleteWhatDependsOn (object=<value optimized
out>, showNotices=0 '\000') at dependency.c:401
#7  0x00000000004b6e90 in RemoveTempRelations () at namespace.c:3234
#8  InitTempTableNamespace () at namespace.c:3066
#9  0x00000000004b70b5 in RangeVarGetCreationNamespace
(newRelation=<value optimized out>) at namespace.c:351
#10 0x0000000000536e13 in DefineRelation (stmt=0x638da00, relkind=114
'r', ownerId=0) at tablecmds.c:409
#11 0x000000000063c15f in standard_ProcessUtility (parsetree=<value
optimized out>,   queryString=0x6298460 "create temp table temp_defs_table_20068
(symhash char(32), symbolid integer)", params=0x0, isTopLevel=<value
optimized out>,   dest=<value optimized out>, completionTag=<value optimized out>)
at utility.c:512
#12 0x0000000000637d81 in PortalRunUtility (portal=0x61ec860,
utilityStmt=0x62992d0, isTopLevel=1 '\001', dest=0x6299670,
completionTag=0x7ffffa9c1c30 "") at pquery.c:1191
#13 0x00000000006384de in PortalRunMulti (portal=0x61ec860,
isTopLevel=1 '\001', dest=0x6299670, altdest=0x6299670,
completionTag=0x7ffffa9c1c30 "") at pquery.c:1296
#14 0x0000000000639732 in PortalRun (portal=0x61ec860,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x6299670,
altdest=0x6299670, completionTag=0x7ffffa9c1c30 "")   at pquery.c:822
#15 0x00000000006359e5 in exec_simple_query (argc=<value optimized
out>, argv=<value optimized out>, username=<value optimized out>) at
postgres.c:1058
#16 PostgresMain (argc=<value optimized out>, argv=<value optimized
out>, username=<value optimized out>) at postgres.c:3936
#17 0x00000000005f95d6 in BackendRun () at postmaster.c:3560
#18 BackendStartup () at postmaster.c:3247
#19 ServerLoop () at postmaster.c:1431
#20 0x00000000005fb934 in PostmasterMain (argc=<value optimized out>,
argv=<value optimized out>) at postmaster.c:1092
#21 0x000000000058de36 in main (argc=3, argv=0x61dd1d0) at main.c:188
(gdb)

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


pgsql-hackers by date:

Previous
From: Darren Duncan
Date:
Subject: Re: transformations between types and languages
Next
From: Peter Geoghegan
Date:
Subject: Re: Draft release notes complete