Rusty Conover <rconover@infogears.com> writes:
> [ same stack trace for the simplified test case ]
Ah, got it finally. There *is* a relcache flush happening during INSERT
in the 8.4 code, because of FSM extension:
(gdb) bt
#0 RegisterRelcacheInvalidation (dbId=40264, relId=848094) at inval.c:439
#1 0x000000000067a30d in CacheInvalidateRelcache (relation=0x7f39b88403f0) at inval.c:1141
#2 0x00000000005c9c45 in fsm_extend (fsm_nblocks=<value optimized out>, rel=<value optimized out>) at
freespace.c:589
#3 fsm_readbuf (fsm_nblocks=<value optimized out>, rel=<value optimized out>) at freespace.c:522
#4 0x00000000005ca2e4 in fsm_set_and_search (rel=0x9d48, addr=<value optimized out>, slot=0, newValue=220 '\334',
minValue=200 '\310') at freespace.c:608
#5 0x00000000005ca675 in RecordAndGetPageWithFreeSpace (rel=0x7f39b88403f0, oldPage=<value optimized out>,
oldSpaceAvail=<valueoptimized out>, spaceNeeded=<value optimized out>) at freespace.c:163
#6 0x0000000000464149 in RelationGetBufferForTuple (relation=0x7f39b88403f0, len=<value optimized out>,
otherBuffer=0,options=<value optimized out>, bistate=<value optimized out>) at hio.c:303
#7 0x0000000000462e77 in heap_insert (relation=0x7f39b88403f0, tup=0x14aa580, cid=<value optimized out>, options=0,
bistate=0x0)at heapam.c:1890
This code path doesn't exist in CVS HEAD, which means (I think) that the
given test case can't fail in HEAD. I think I got myself confused by
experimenting variously with HEAD and 8.4 in regular and
CLOBBER_CACHE_ALWAYS modes --- only one of those four combinations will
exhibit a failure with this test case.
Although the particular case apparently can't arise in HEAD, I'm going
to apply Heikki's patch there anyway, since there's clearly a risk of
related problems.
regards, tom lane
