Re: [HACKERS] generic LONG VARLENA

> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> If we are going to do this, we ought also think about solving the
> >> generic memory-leakage problem at the same time.  No point in having
> >> to revisit all the same code later to deal with that issue.
> 
> > I have a good fix for this.  My patch suggested the varlena routine
> > pfree the pointer returned from expand_long().  No need for that.  With
> > an LRU cache, we can have the cache itself free the old values.
> 
> Oooh, that's a thought.  Sort of like applying TupleTableSlot to
> individual datum values.
> 
> > There aren't any cases where the varlena access routines access more
> > than two varlena values at the same time.
> 
> Huh?  The standard operators on varlena types access at least three (two
> inputs and a result), and multi-argument functions could access more.
> Also think about functions written in PLs: they could invoke a large
> amount of computation, and would still expect to be able to access their
> original input arguments.
> 
> I'd feel more comfortable with explicit reference counting.  Perhaps
> we could make an exception for function return values: the cache
> guarantees to hold onto a function return value for a little while
> even though no one is holding a refcount on it at the instant it's
> returned.  Functions (including PL functions) that want to access
> varlena values across any significant amount of computation would
> have to bump the refcount on those values somehow.

I just checked the code, and I don't see any places where a varlena is
returned that isn't palloc'ed inside the function, so the cache memory
never makes it out of the routines.

However, I see any reference to VARDATA could be a problem because it
assume the data is there, and not in the long* relations.  I could
probably figure out which ones need expanding.  They are mostly system
table accesses.  The others go through adt or are output to the user.

> 
> > I am excited about the long data type.  This is _the_ way to do long
> > data types.  Have any of the commercial databases figured out this way
> > to do it.  I can't imagine a better system.
> 
> I think we are working on some really cool ideas here.  But I *don't*
> think we have a solid enough hold on all the details that we can expect
> to implement it and ship it out one-two-three.  Thus my feeling that
> this is for 7.1 not 7.0...

We have gotten pretty far in two days.  This long tuple stuff is not as
difficult as foreign key because I can actually figure out what is
happening with the long types, while foreign key is a complete mystery
to me.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026