Re: [HACKERS] Last thoughts about LONG

Tom Lane wrote:

> wieck@debis.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@debis.com (Jan Wieck) #