Thread: NOTICE: SIReadEntryData: cache state reset TRAP: Failed Assertion("!(RelationNameCache->hctl->nkeys == 10):", File: "relcache.c", Line: 1458)

freebsd 2.2.7 (PII system)
gcc 2.95.1
postgres 6.5.1 no patches

I get these sporadically and I can't trace them to any particular thing other than heavy access.

query: select serverSequence from estoret order by serverSequence
ProcessQuery
NOTICE:  SIReadEntryData: cache state reset
TRAP: Failed Assertion("!(RelationNameCache->hctl->nkeys == 10):", File: "relcache.c", Line: 1458)

!(RelationNameCache->hctl->nkeys == 10) (0)


#0  0x20214151 in ?? ()
#1  0x202139c3 in ?? ()
#2  0x109648 in ExcAbort ()
#3  0x1095a7 in ExcUnCaught ()
#4  0x1095fa in ExcRaise ()
#5  0x108e3a in ExceptionalCondition ()
#6  0x105f33 in RelationCacheInvalidate ()
#7  0x1040ef in ResetSystemCaches ()
#8  0xc96c1 in SIReadEntryData ()
#9  0xc8d4b in InvalidateSharedInvalid ()
#10 0x104372 in DiscardInvalid ()
#11 0x2f7b8 in AtStart_Cache ()
#12 0x2f78a in CommandCounterIncrement ()
#13 0xd3754 in pg_exec_query_dest ()
#14 0xd35a4 in pg_exec_query ()
#15 0xd5118 in PostgresMain ()
#16 0xb44a8 in DoBackend ()
#17 0xb3f63 in BackendStartup ()
#18 0xb3246 in ServerLoop ()
#19 0xb2a3f in PostmasterMain ()
#20 0x69aa7 in main ()

Jason Venner <jason@idiom.com> writes:
> I get these sporadically and I can't trace them to any particular
> thing other than heavy access.

> NOTICE:  SIReadEntryData: cache state reset
> TRAP: Failed Assertion("!(RelationNameCache->hctl->nkeys == 10):", File: "relcache.c", Line: 1458)
> !(RelationNameCache->hctl->nkeys == 10) (0)

Yeah.  What's happening is that the SI message buffer is overflowing and
you are hitting a bug in the code that is supposed to recover from that
condition.  (I posted a long discussion of what SI is all about a few
days ago and don't feel like repeating it --- check the list archives.)
There are several bugs in that area :-(.

I believe I have fixed all the problems with SI overflow recovery for
6.6, but that's part of a rather extensive set of changes to relcache.c
and sinvaladt.c.  We are talking about back-patching these changes along
with the not-yet-done relation locking change to make a 6.5.3.

In the meantime, your best bet might be to reduce the probability of SI
overflow by raising MAXNUMMESSAGES in src/include/storage/sinvaladt.h.
It's standardly 4000, but the space per message is only a couple dozen
bytes, so you could probably make it 10 times that without hurting
much...
        regards, tom lane