Обсуждение: Lifecycle management

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:

1. The structure is copied into a special MemoryContext that PL/Java 
manages and is thus valid throughout the life cycle of the wrapper.
2. The structure is considered "call local", i.e. the wrapper is 
invalidated when the current call-handler call returns.
3. The structure has an associated callback that can be used in order to 
invalidate the wrapper when the structure is freed up.

At present, the only wrapper that uses category #3 is the Portal wrapper 
and that solution is a bit ugly. I currently replace the portal->cleanup 
function pointer with a function that invalidates the wrapper and then 
calls the original cleanup. This solution will break as soon as someone 
decides that different portals can have different cleanup functions (and 
I guess that's the reason for having the function pointer in the first 
place).

I need some advice on how to improve this. The issues that I see are:

- the portal callback problem. Would it be feasible to install a proper 
callback registration on portals?
- unnecessary copying. Since several structures doesn't have callbacks 
but can be copied, I'm always copying them.
- 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).

Ideally, I'd like callback functionality on a number of structures, 
Portal, HeapTuple, TupleDesc, Relation, LargeObjectDesc, and 
ExecutionPlan in particular.

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

Kind regards,
Thomas Hallgren

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.

Martijn van Oosterhout wrote:
> 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.
>
>   
I guess some of my questions originate in lack of knowledge about the 
rules you mention. I haven't been able to find documentation that 
explains them thoroughly and I haven't been able to fully deduct it from 
looking at the backend code (partly due to my own laziness perhaps). 
Another reason is that I'm trying to marry two ways of handling object 
life cycle, the Java style using a garbage collector and the backend 
style, stacking MemoryContext's. I want the marriage to be somewhat 
generic and resilient to change.

Let's assume that one Java function executes a query through SPI. The 
query in itself calls another Java function that returns SET OF <complex 
type>. Each tuple returned from this query could potentially be used 'as 
is' in the caller, i.e. the inner Java function could use the same 
wrapper instance as the caller Java function if I had full control over 
the life cycle of the HeapTuple's that are passed on. At present, I copy 
those tuples and use different wrappers.
> 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.
>   
OK, I suspected that. My hope was that functions like heap_freetuple() 
was guaranteed to be called when a tuple was freed up. I realize that 
deleting or resetting a MemoryContext makes such calls unnecessary.
> 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 have experimented with code that does this. I extend existing contexts 
by swapping function pointers, installing interceptors for certain 
calls. I can for instance extend the alloc method with something that 
creates a double-linked list by which I can keep track of the objects 
that are allocated and a pointer to the associated wrapper. When the 
context is destroyed or reset, I can traverse that list. Trouble is, 
when I get hold of the context it's already too late since some objects 
have been allocated already and the context doesn't expose a method that 
allows me to iterate over it's objects.

If I knew that all objects that I look at indeed are allocated in a 
MemoryContexts and not on the stack or as a part of the allocation of 
another object, then I could make assumptions that would enable a 
generic and safe way of doing this. From my experience though, I can't 
make such assumptions.

Another concern is of course that replacing function pointers in memory 
contexts seems a bit dangerous overall. It violates the separation of 
concern between my module and the backend way more than I'm comfortable 
with. If there was a mechanism by which I could influence what kind of 
context that should be used for the query nodes etc. things would be 
different of course. Then again, what happens if such a mechanism 
existed and several different PL's wanted to influence that in their own 
ways.
>> - 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.
>   
Nothing probably since I always copy such nodes and keep them until the 
finalizer is called that destroys the wrapper. It would be nice though, 
if the original producer of the tuple could be told to allocate it in a 
designated context from the very start and then *never* free it up. That 
way, PL/Java would assume full responsibility for the object destruction 
and no copying would be necessary. Today, a HeapTuple that is returned 
seems to be freed-up by either calls to heap_freetuple or by destroying 
the context in which it was allocated.
>   
>> 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.
>   
The primary reason for my desire to wrap the HeapTupleHeader in a fully 
fledged HeapTuple is a) then I can call the heap_copytuple to get a safe 
durable copy and b) I don't need two different wrapper objects (AFAIK, 
there is no heap_copytupleheader function).

Again, I need advice. I'm not fully aware of all the semantics involved, 
how memory contexts are allocated and destroyed, what objects that can 
be trusted to originate from memory contexts etc. Pointers to doc's or 
code that makes this clearer will help a great deal.

Kind Regards,
Thomas Hallgren

On Sat, Oct 22, 2005 at 10:09:12PM +0200, Thomas Hallgren wrote:
> I guess some of my questions originate in lack of knowledge about the
> rules you mention. I haven't been able to find documentation that
> explains them thoroughly and I haven't been able to fully deduct it from
> looking at the backend code (partly due to my own laziness perhaps).
> Another reason is that I'm trying to marry two ways of handling object
> life cycle, the Java style using a garbage collector and the backend
> style, stacking MemoryContext's. I want the marriage to be somewhat
> generic and resilient to change.

Well, the stuff is mostly in the comments of the executor, but
src/backend/executor/README  has some info.

> Let's assume that one Java function executes a query through SPI. The
> query in itself calls another Java function that returns SET OF <complex
> type>. Each tuple returned from this query could potentially be used 'as
> is' in the caller, i.e. the inner Java function could use the same
> wrapper instance as the caller Java function if I had full control over
> the life cycle of the HeapTuple's that are passed on. At present, I copy
> those tuples and use different wrappers.

You might have to check the SPI documentation to be sure, but the
resultset you receive will be valid until leave that SPI invocation
(the call to SPI_finish). The documentation for SPI_exec says as much.

The SPI interface will collect all the rows from the called function
and return them as a block in a single memory context.

Conversely, if a Java function returns a tuple, the memory it returns
that in only needs to be valid until the next call to your function at
which point you can overwrite it. If the caller still wanted the old
tuple, it would have copied it already.

There is a bit of documentation somewhere that states that nodes should
code like:

Node
{ ResetContext(); allocate tuples in context return
}

Ah yes, in src/backend/utils/mmgr/README, under "Transient contexts
during execution".

> If I knew that all objects that I look at indeed are allocated in a
> MemoryContexts and not on the stack or as a part of the allocation of
> another object, then I could make assumptions that would enable a
> generic and safe way of doing this. From my experience though, I can't
> make such assumptions.

You're right, they're not...

> Nothing probably since I always copy such nodes and keep them until the
> finalizer is called that destroys the wrapper. It would be nice though,
> if the original producer of the tuple could be told to allocate it in a
> designated context from the very start and then *never* free it up. That
> way, PL/Java would assume full responsibility for the object destruction
> and no copying would be necessary. Today, a HeapTuple that is returned
> seems to be freed-up by either calls to heap_freetuple or by destroying
> the context in which it was allocated.

Well, consider that the output of a seqscan node is a pointer to the
actual tuple in the disk buffer in shared memory, you have to realise
that such a scheme is *tricky* at best. See that memory management for
the reasoning behind the current system.

Now, the SPI interface takes care of copying the tuples into a context
long-lived enough to survive your function. Additionally, it provides
functions to move them into a context for returning to your caller. You
obviously need to be doing something tricky to run into problems...

> The primary reason for my desire to wrap the HeapTupleHeader in a fully
> fledged HeapTuple is a) then I can call the heap_copytuple to get a safe
> durable copy and b) I don't need two different wrapper objects (AFAIK,
> there is no heap_copytupleheader function).

Actually, I was wondering where you were getting the HeapTupleHeader's
from. All the functions dealing with tuples (like heap_form_tuple,
heap_deform_tuple, etc) take HeapTuples. HeapTupleHeaders are not
really passed around. Are you making your own code to create tuples?

heap_copytupleheader == memcpy. The data is the raw data. You pretty
much need to have the HeapTuple just to know how big the tuple is as
the on disk version doesn't have a length attribute, that's just an
artifact of the in memory tuples.

Look in include/access/htup.h, you'll see that the length attribute
is in a union overlaying the xmin/xmax values. See the comment above
HeapTupleData about how tuples can be allocated

> Again, I need advice. I'm not fully aware of all the semantics involved,
> how memory contexts are allocated and destroyed, what objects that can
> be trusted to originate from memory contexts etc. Pointers to doc's or
> code that makes this clearer will help a great deal.

Read the READMEs in utils/mmgr and executor, they explain a lot.

Hope this helps,
--
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.

Martijn,
Thanks a lot. Your insights and pointers will help me a great deal. The 
answer to your question where I get HeapTupleHeader's from is that 
that's what a call-handler receive when you declare a function that 
takes complex parameters.

Kind Regards,
Thomas Hallgren