Lifecycle management - Mailing list pgsql-hackers

From Thomas Hallgren
Subject Lifecycle management
Date
Msg-id 435A273C.1080904@tada.se
Whole thread Raw
Responses Re: Lifecycle management
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance