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