Re: [HACKERS] Last thoughts about LONG

Tom Lane wrote:

> wieck(at)debis(dot)com (Jan Wieck) writes:
> > Another bonus would be this: What happens on an UPDATE to a
> > table having LONG attributes? If the attribute is not
> > modified, the OLD LongData will be found in the targetlist,
> > and we'll not waste any space by storing the same information
> > again.
>
> Won't work. If you do that, you have several generations of the
> "primary" tuple pointing at the same item in the "secondary" table.
> There is room in the multiple primary tuples to keep track of their
> committed/uncommitted status, but there won't be enough room to
> keep track in the secondary table.

A really critical point, to think about in depth. And another
point I could have stumbled over.

But it would work anyway.

I assumed up to now, that even under MVCC, and even if
reading dirty, there could be at max one single transaction
modifying one and the same tuple - no? Ignore all the rest
and forget all my comments if your answer is no. But please
tell me how something like RI should ever work RELIABLE in
such an environment. In fact, in that case I would
immediately stop all my efford in FOREIGN KEY, because it
would be a dead end street - so I assume your answer is yes.

My concept, using regular heap access inside of heap access
to act on "secondary" table, means to stamp the same current
xact as for "primary" table into xmax of old, and into xmin
of new tuples for the "secondary" table. And it means that
this operation appears to be atomic if living in a locking
environment.

The only thing I DON'T wanted to do is to stamp xmax and
create new instances in "secondary" table, if no update is
done to the value of the old LONG attribute. Any UPDATE
modifying the LONG value, and INSERT/DELETE of course will
stamp this information and/or create new instances. So the
only thing (because the only difference) to worry about are
unstamped and uncreated instances in "secondary" table -
right?

Since INSERT/DELETE allways act synchronous to the "primary"
table, and and UPDATE modifying the LONG too, the only thing
left to worry about is an UPDATE without updating the LONG.

In this scenario, a "secondary" tuple of a not updated
"primary" LONG will have an older, but surely committed,
xmin. And it's xmax will be either infinite, or aborted. So
it is visible - no other chance. And that's good, because at
the time beeing, the updater of the "primary" tuple does a
NOOP on the "secondary". And this (extended) part of the
"primaries" tuple information is absolutely unaffected,
regardless if it's transaction will commit or rollback.

Well, your concern is again valid. This concept MIGHT need to
force a NON-MVCC locking scheme for "secondary" tables. But
as far as I learned from the RI stuff, that isn't a problem
and therefore current Jackpot value to be added to Vadim's
account.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #