Re: Storing a dynahash for an entire connection or

On Mon, 2006-11-27 at 20:11 +0000, Tom Dunstan wrote:
> That's the obvious solution (or perhaps in CurTransactionContext), but 
> when the function is called in a subsequent transaction, how does it 
> determine that the static pointer was allocated from a context which has 
> since vanished?

If you're content with your allocations never being automatically
released for the duration of the session (which sounds like the behavior
Greg would like, I'm guessing), you can just allocate the hash table in
TopMemoryContext, in which case you wouldn't need to worry about the
context of allocation vanishing beneath your feet.

A nicer technique is to create a new child context of TopMemoryContext,
and use that context for all the session-duration allocations made by
your extension. This avoids making too many allocations in
TopMemoryContext, lets you get information on the allocations made by
your UDF via MemoryContextStats(), and allows you to easily release the
UDF's allocations by deleting or resetting a single memory context. For
example, deleting your UDF's context in _PG_fini() cleanly avoids
leaking memory when your shared object is unloaded from the backend.

BTW, one common error when using long-lived memory contexts is assuming
that allocations made in these contexts will be released after an
elog(ERROR). This is not true when the memory context's lifetime exceeds
that of a single transaction (as is the case with TopMemoryContext).

-Neil