Re: [HACKERS] generic LONG VARLENA

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026