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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
