Re: Regression test failure date.
От | Tom Lane |
---|---|
Тема | Re: Regression test failure date. |
Дата | |
Msg-id | 16847.1059440021@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Regression test failure date. (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Regression test failure date.
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: