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

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 #

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

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?

One should check all places from where DataFill called...

Btw, I've found that I unlocked buffer in heap_insert *after* WriteBuffer -
fixed.

2Jan - please note NO ELOG(ERROR)... comment in heap_update: can you move
toast
code below xlog one?

Vadim

"Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:

One should check all places from where DataFill called...

I did. All the other ones start with an already-zeroed infomask.

I think this change is correct as far as it goes, though we still
have bugs elsewhere...

regards, tom lane

Mikheev, Vadim wrote:

2Jan - please note NO ELOG(ERROR)... comment in heap_update: can you move
toast
code below xlog one?

Will take a look if that matters.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #