Re: Lifecycle management - Mailing list pgsql-hackers

On Sat, Oct 22, 2005 at 01:49:16PM +0200, Thomas Hallgren wrote:
> PL/Java has gone through a series of stability improvements over the
> last couple of weeks. Now it's time to perhaps improve things even more
> but that requires a little help from PostgreSQL itself (nothing related
> to threads though ;-) )
>
> PL/Java has various "wrapper" objects for PostgreSQL structures. In
> essence, such a wrapper holds on to a pointer to some structure and
> dispatch calls to backend functions. The challenge is to make sure that
> the wrapped pointer is valid at all times. PL/Java uses three distinct
> approaches to accomplish this:

Im curious. What objects are you holding pointers to where you don't
know how long the lifetime is? The backend has pretty clear rules about
how long something lives for.

Adding callbacks is going to be a pain, primarily because (AIUI) most
structures not explicitly deallocated but simply dropped when the
memory context is freed. Hence, no callbacks can be called because not
even the backend knows exactly when the object in question is not
valid. To do so would require registration of every object with its
associated memory context is destroyed, just so we can call them. The
whole point of the current memory management is to avoid that sort of
overhead.

The only other possibility would be to hook into the memory management
itself so you can called when the context is reset. Except you still
don't know the objects in it...

> - I'd like to know when the return value of a function goes out of
> scope. "call-local" is often premature since the structure might survive
> and be used in the calling function (which may be Java also).

When it comes to plan execution, at each node the tuple is returned is
assumed to valid until the next call to that node. If a node further up
wants to keep it longer (eg Sort node), only then does it need to be
copied. I don't know what that means in your context.

> Hmm, and the HeapTupleHeader that is passed to RECORD functions, is
> there an easy way to transform that into a HeapTuple?

HeapTupleHeader is a pointer to HeapTupleHeaderData, ie the actual
data. HeapTuple is a pointer to HeapTupleData which contains a
HeapTupleHeader and info about the memory context and such. You really
only deal with the latter unless you're extracting data...

More info would make things a lot clearer.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.