Rusty Conover <rcono...@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=<value optimized 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
