OK, on it now! ---------------------------------------------------------------------------
Tom Lane wrote: > I said: > >> I have a theory about the failures that occur while creating tables. > >> If a relcache flush were to occur due to SI buffer overrun between > >> creation of the new rel's relcache entry by RelationBuildLocalRelation > >> and completion of the command, then you'd see an error exactly like the > >> above, because the relcache would try to rebuild the cache entry by > >> reading the pg_class and pg_attribute rows for the relation. > > After further study, though, the above theory falls flat on its face: > the relcache does *not* attempt to rebuild new relcache entries after > an SI overrun (see the comments to RelationCacheInvalidate). So I'm > back to wondering what the heck is causing any of these messages. > > I think we really need to see a stack trace from one of the failures. > Could you try running CVS tip with an "abort()" call replacing the > "relation %u deleted while still in use" elog? (It's line 1797 > in src/backend/utils/cache/relcache.c in CVS tip.) Then when you > get the failure, get a stack trace with gdb from the core dump. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
