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