Simon Riggs <si...@2ndquadrant.com> writes:
> On 24 November 2013 16:02, Paul Ramsey <pram...@cleverelephant.ca> wrote:
>> We do the dance because its how we always have and dont know any other
>> way, any better way. :) The usual explanation. Is there any place you can
>> point to that demonstrates your technique?
> src/backend/utils/mmgr/README
> You can create memory contexts as children of other contexts, so for
> example you might create "PostGIS Cache Context" as a sub-context of
> TopTransactionContext. So it can be created dynamically as needed and
> will automatically go away at end of xact.
The real question of course is whether transaction-level caching is
appropriate for what they're storing. If they want only statement-level
caching then using fn_extra is often the right thing.
Also note that having the cache go away is the easy part. The hard part
is knowing whether you've created it yet in the current transaction, and
finding it if you have. The usual method is to keep a static variable
pointing to it, and plugging into the transaction cleanup callback
mechanism with a routine that'll reset the pointer to NULL at transaction
end. For examples, look for callers of RegisterXactCallback().
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
