RE: relation ### modified while in use

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> > BTW,I sometimes see
> > ERROR: SearchSysCache: recursive use of cache 10(16)
> > under small MAXNUMMESSAGES environment.
> > I'm not sure about the cause but suspicious if sufficiently
> > many system relations are nailed for "cache state reset".
>
> Does this occur after a prior error message? I have been suspicious
> because there isn't a mechanism to clear the syscache-busy flags during
> xact abort. If we elog() out of a syscache fill operation, seems like
> the busy flag will be left set, leading to exactly the above error on
> later xacts' attempts to use that syscache. I think we need an
> AtEOXact_Syscache routine that runs around and clears the busy flags.
> (In the commit case, perhaps it should issue debug notices if it finds
> any that are set.)
>

I don't know if I've seen the cases you pointed out.
I have the following gdb back trace. Obviously it calls
SearchSysCache() for cacheId 10 twice. I was able
to get another gdb back trace but discarded it by
mistake. Though I've added pause() just after detecting
recursive use of cache,backends continue the execution
in most cases unfortunately.
I've not examined the backtrace yet. But don't we have
to nail system relation descriptors more than now ?
"cache state reset" could arrive at any heap_open().

Not that #0 corresponds to pause() and line numbers may
be different from yours.

#0 0x40163db7 in __libc_pause ()
#1 0x8141ade in SearchSysCache (cache=0x825b89c, v1=17113, v2=0, v3=0,
v4=0)
at catcache.c:1026
#2 0x8145bd0 in SearchSysCacheTuple (cacheId=10, key1=17113, key2=0,
key3=0,
key4=0) at syscache.c:505
#3 0x807a100 in IndexSupportInitialize (indexStrategy=0x829d230,
indexSupport=0x829ab2c, isUnique=0x829cf26 "", indexObjectId=17113,
accessMethodObjectId=403, maxStrategyNumber=5, maxSupportNumber=1,
maxAttributeNumber=2) at istrat.c:561
#4 0x81437cd in IndexedAccessMethodInitialize (relation=0x829cf10)
at relcache.c:1180
#5 0x8143599 in RelationBuildDesc (buildinfo={infotype = 1, i = {
info_id = 17113, info_name = 0x42d9 <Address 0x42d9 out of
bounds>}},
oldrelation=0x829cf10) at relcache.c:1095
#6 0x8143f8d in RelationClearRelation (relation=0x829cf10, rebuildIt=1
'\001')
at relcache.c:1687
#7 0x81440fa in RelationFlushRelation (relationPtr=0x8246f8c,
skipLocalRelations=1) at relcache.c:1789
#8 0x80d02e3 in HashTableWalk (hashtable=0x823941c,
function=0x81440d0 <RelationFlushRelation>, arg=1) at hasht.c:47
#9 0x81442b5 in RelationCacheInvalidate () at relcache.c:1922
#10 0x81421bd in ResetSystemCaches () at inval.c:559
#11 0x810302b in InvalidateSharedInvalid (
invalFunction=0x8142150 <CacheIdInvalidate>,
resetFunction=0x81421b0 <ResetSystemCaches>) at sinval.c:153
#12 0x8142332 in DiscardInvalid () at inval.c:722
#13 0x8104a9f in LockRelation (relation=0x8280134, lockmode=1) at lmgr.c:151
#14 0x807427d in heap_open (relationId=16580, lockmode=1) at heapam.c:638
#15 0x8141b54 in SearchSysCache (cache=0x825b89c, v1=17116, v2=0, v3=0,
v4=0)
at catcache.c:1049
#16 0x8145bd0 in SearchSysCacheTuple (cacheId=10, key1=17116, key2=0,
key3=0,
key4=0) at syscache.c:505
#17 0x80921d5 in CatalogIndexInsert (idescs=0xbfffeaac, nIndices=2,
heapRelation=0x82443d0, heapTuple=0x827a4c8) at indexing.c:156
#18 0x808e6e7 in AddNewAttributeTuples (new_rel_oid=137741,
tupdesc=0x8279904)
at heap.c:659
#19 0x808e9c3 in heap_create_with_catalog (relname=0x82a02c4 "bprime",
tupdesc=0x8279904, relkind=114 'r', istemp=0 '\000',
allow_system_table_mods=0 '\000') at heap.c:911
#20 0x80c320d in InitPlan (operation=CMD_SELECT, parseTree=0x8288100,
plan=0x8277d70, estate=0x8277dfc) at execMain.c:729
#21 0x80c2af1 in ExecutorStart (queryDesc=0x8278c14, estate=0x8277dfc)
at execMain.c:131
#22 0x810c327 in ProcessQuery (parsetree=0x8288100, plan=0x8277d70,
dest=Remote) at pquery.c:260
#23 0x810aeb5 in pg_exec_query_string (
query_string=0x8287c58 "SELECT *\n INTO TABLE Bprime\n FROM tenk1\n
WHERE unique2 < 1000;", dest=Remote, parse_context=0x822efb4) at
postgres.c:820
#24 0x810be42 in PostgresMain (argc=4, argv=0xbfffed74, real_argc=4,
real_argv=0xbffff654, username=0x823c881 "reindex") at postgres.c:1808
#25 0x80f3913 in DoBackend (port=0x823c618) at postmaster.c:1963
#26 0x80f34e6 in BackendStartup (port=0x823c618) at postmaster.c:1732
#27 0x80f285a in ServerLoop () at postmaster.c:978
#28 0x80f22f4 in PostmasterMain (argc=4, argv=0xbffff654) at
postmaster.c:669
#29 0x80d41bd in main (argc=4, argv=0xbffff654) at main.c:112

Regards.
Hirsohi Inoue