Re: Regression test failure date. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Regression test failure date.
Date
Msg-id 16847.1059440021@sss.pgh.pa.us
Whole thread Raw
In response to Re: Regression test failure date.  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Regression test failure date.  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: Joe Conway
Date:
Subject: Re: an aggregate array function
Next
From: Bruce Momjian
Date:
Subject: Re: Regression test failure date.