  Date: Monday, July  3, 2000 @ 19:09:54
Author: wieck

Update of /home/projects/pgsql/cvsroot/pgsql/src/backend/utils/adt
     from hub.org:/tmp/cvs-serv55060/backend/utils/adt

Modified Files:
	arrayfuncs.c cash.c char.c float.c formatting.c int.c int8.c 
	lztext.c mac.c nabstime.c network.c oid.c oracle_compat.c 
	pg_lzcompress.c regproc.c ruleutils.c timestamp.c varbit.c 
	varchar.c varlena.c version.c 

-----------------------------  Log Message  -----------------------------

TOAST

    WARNING: This is actually broken - we have self-deadlocks
	         due to concurrent changes in buffer management.
			 Vadim and me are working on it.

Jan



Mon, 3 Jul 2000 19:09:56 -0400 (EDT)
Jan Wieck <wieck>
pgsql/src/backend/utils/adt (arrayfuncs.c cash.c char.c float.c
	formatting.c int.c int8.c lztext.c mac.c nabstime.c network.c
	oid.c oracle_compat.c pg_lzcompress.c regproc.c ruleutils.c
	timestamp.c varbit.c varchar.c varlena.c version.c)
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

Mon, 03 Jul 2000 19:23:51 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [COMMITTERS] TOAST
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 regression test
    -   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 off to  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 a little,
    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 I posted
    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 #



Tue, 4 Jul 2000 01:57:07 +0200 (MEST)
JanWieck@t-online.de (Jan Wieck)
Re: Re: [COMMITTERS] TOAST
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

Mon, 03 Jul 2000 20:11:22 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: [COMMITTERS] TOAST 
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 #




Tue, 4 Jul 2000 02:52:38 +0200 (MEST)
JanWieck@t-online.de (Jan Wieck)
Re: Re: [COMMITTERS] TOAST
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

Mon, 03 Jul 2000 22:19:52 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: Re: [COMMITTERS] TOAST 