Re: [HACKERS] LONG varsize - how to go on

Bruce Momjian wrote:

> >     I  know  that  I  can  deal with a bunch of deferred patches,
> >     staying in sync with CURRENT and having new features only  as
> >     patches.  But  that  worx only as long as I have most catalog
> >     changes in CURRENT. One single concurrent catalog change  can
> >     cost me days of work in the worst case otherwise.
>
> The Feb 1 date is not set in stone.  If you would prefer March 1, we can
> look at that option.

    Let's see how far I can get it in the next 3-4 weeks. Then it
    should have turned out if it's worth to delay the release for
    another couple of weeks or not.

    Had  an  Idea  just  as  I  wrote the (now deleted) text that
    appeared here :-)

    The problem I wanted to write about are  sections  (possible,
    even  if  I don't know about one I haven't written myself :-)
    in the code,  where  a  Datum  is  explicitly  or  implicitly
    casted, to get access to vl_len and vl_dat.

    Well,  I intend to redefine the varlena struct and rename any
    macro that deals with it. This way I'll catch any location in
    the code, that does anything with variable size attributes in
    a usual way.

    We wanted to use the top 2 bits of vl_len for flags,  leaving
    us  a theoretical maximum size of 1GB for one single extended
    attribute value.  Since I want to leave out  the  compression
    part  for  now, I could set the compression info bit ALLWAYS.
    That would force any  part  of  the  code,  where  the  above
    casting  (abuse)  occurs,  to  immediately CRASH at first hit
    (would allocate or access >=1G of memory and I think this  is
    enough to trigger a crash somewhere).  If such a setup passes
    BETA, I'll feel comfortable with it.


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) #