Thread: Re: [COMMITTERS] TOAST
Jan Wieck <wieck@hub.org> writes:
> TOAST
> WARNING: This is actually broken - we have self-deadlocks
> due to concurrent changes in buffer management.
> Vadim and me are working on it.
Uh, exactly how broken would that be? Do you mean that the CVS tip
is now nonfunctional and no one else can expect to get any useful
work done? Or do the problems only arise in special cases?
regards, tom lane
Tom Lane wrote: > Jan Wieck <wieck@hub.org> writes: > > TOAST > > WARNING: This is actually broken - we have self-deadlocks > > due to concurrent changes in buffer management. > > Vadim and me are working on it. > > Uh, exactly how broken would that be? Do you mean that the CVS tip > is now nonfunctional and no one else can expect to get any useful > work done? Or do the problems only arise in special cases? My usual sequence is - construct a patch - run "cvs update" - apply my patch to a local copy of the CVS tree - run the regressiontest - apply my patch to the checked out tree - cvs commit That avoids alot of trouble. The problems only arise if someone uses a new command to activate tuple move offto the secondary relation. I had some time where I wasn't able to compile the current CVS at all (my old, years grown, box got screwed up alittle, and my new notebook wasn't installed to a useful level). The problem now is, that if the toaster really moved off values into the secondary relation, the backend locks up when trying to append a main tuple. Vadim changed something recently in heap_insert() and I already gave him a call. He'll look at the test case Iposted to CORE soon. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
With current CVS tip, I get an Assert() failure during initdb.
#7 0x19268c in ExceptionalCondition ( conditionName=0x76578 "!(TransactionIdIsCurrentTransactionId(tuple->t_xmax))
", exceptionP=0x4000a650, detail=0x0, fileName=0x401933ed "", lineNumber=202) at assert.c:73
#8 0x1a1b44 in HeapTupleSatisfiesNow (tuple=0x400b4680) at tqual.c:233
#9 0x89ad8 in heapgettup (relation=0x401804f0, tuple=0x40166a24, dir=1, buffer=0x40166a58, snapshot=0x0, nkeys=1,
key=0x40167ab0)at heapam.c:439
#10 0x8ac48 in heap_getnext (scandesc=0x0, backw=0) at heapam.c:1028
#11 0x18df5c in RelationBuildRuleLock (relation=0x4017dbe8) at relcache.c:801
#12 0x18e1cc in RelationBuildDesc (buildinfo={infotype = 1, i = { info_id = 17280, info_name = 0x4380
"�\211�\236g5?\215�D�\205\021\004�\a\230^��`\2209�[
� �E�T�\"LG��\005*<�\225�V\211�\016\032\020X��^�\e35\216y�\205�\013��<\036��"}}
, oldrelation=0x4017dbe8) at relcache.c:993
#13 0x18eb20 in RelationClearRelation (relation=0x4017dbe8, rebuildIt=0 '\000') at relcache.c:1485
#14 0x18eca0 in RelationFlushRelation (relationPtr=0x0, skipLocalRelations=2) at relcache.c:1584
#15 0x18eebc in RelationIdInvalidateRelationCacheByRelationId ( relationId=17280) at relcache.c:1653
#16 0x18c574 in CacheIdInvalidate (cacheId=1663383, hashIndex=2, pointer=0x40195ffc) at inval.c:544
#17 0x18c6f0 in InvalidationMessageCacheInvalidate (message=0x4018ef4c) at inval.c:658
#18 0x18c0b8 in LocalInvalidInvalidate (invalid=0x4018ef4c "r", function=0x4000da7a <DINFINITY+9970>, freemember=1
'\001')at inval.c:173
#19 0x18c8a4 in ImmediateLocalInvalidation (send=0 '\000') at inval.c:808
#20 0xa6eb8 in AtCommit_LocalCache () at xact.c:714
#21 0xa6cc0 in CommandCounterIncrement () at xact.c:535
#22 0x145e0c in pg_exec_query_dest ( query_string=0x40174320 "CREATE VIEW pg_user AS SELECT", ' ' <repeats 13
times>,"usename,", ' ' <repeats 13 times>, "usesysid,", ' ' <repeats 13 times>, "usecreatedb,", ' ' <repeats 13 times>,
"usetrace,",' ' <repeats 13 times>, "usesuper,", ' ' <repeats 13 times>, "usecatupd,", ' ' <repeats 13 times>,
"'********'::tex"...,dest=Debug, parse_context=0x40195ffc) at postgres.c:670
#23 0x146f44 in PostgresMain (argc=1073753344, argv=0x67800, real_argc=7, real_argv=0x7b03a6d8) at postgres.c:1584
#24 0xed708 in main (argc=7, argv=0x7b03a6d8) at main.c:103
Any ideas?
regards, tom lane
Tom Lane wrote: > With current CVS tip, I get an Assert() failure during initdb. > > #7 0x19268c in ExceptionalCondition ( > conditionName=0x76578 "!(TransactionIdIsCurrentTransactionId(tuple->t_xmax)) > ", exceptionP=0x4000a650, detail=0x0, fileName=0x401933ed "", lineNumber=202) > at assert.c:73 > > [...] > > Any ideas? Added --enable-cassert to my default configure switches. Hmmm - with my latest changes I get the same, without them I don't. Will backout the changes if I cannot find it quickly. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com #
JanWieck@t-online.de (Jan Wieck) writes:
> Hmmm - with my latest changes I get the same, without them I
> don't. Will backout the changes if I cannot find it quickly.
The problem appears to be that DataFill() is invoked on the tuple
after toasting, and it forces the infomask to zero, losing any
transaction status bits that may have been there. I think perhaps
line 93 of heaptuple.c should be
*infomask &= HEAP_XACT_MASK;
not
*infomask = 0;
Comments anyone?
regards, tom lane