Re: Storing a dynahash for an entire connection or transaction? - Mailing list pgsql-hackers

From Tom Dunstan
Subject Re: Storing a dynahash for an entire connection or transaction?
Date
Msg-id 456B4689.7060307@tomd.cc
Whole thread Raw
In response to Re: Storing a dynahash for an entire connection or transaction?  (Volkan YAZICI <yazicivo@ttnet.net.tr>)
Responses Re: Storing a dynahash for an entire connection or  (Neil Conway <neilc@samurai.com>)
List pgsql-hackers
Volkan YAZICI wrote:
>> What I'd like to do is change the way I store this hash so that it 
>> doesn't need to be as frequently updated. I'm open to most any solution. 
>> One type rarely ever has new values (maybe once every several months) 
>> and the other gets new values once a night.
> 
> You may want to cache these values using a static variable (which will
> make itself to be valid per session) that stores its values in the
> (for instance) TopTransactionContext.

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? I suppose that you could store the memory context 
pointer for later comparison, but while it seems unlikely that you'd get 
the same pointer twice in a row, that's not exactly a guarantee.

I note (reading src/backend/utils/mmgr/README) that there are reset and 
delete methods attached to memory contexts, so perhaps the best way to 
accomplish this would be to create a separate memory context as a child 
of CurTransactionContext, and register a cleanup function which could 
clear the static var when the context is torn down. I'm assuming that 
those methods do get called in such cases, but I haven't delved much.

Cheers

Tom



pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: PrivateRefCount (for 8.3)
Next
From: Alvaro Herrera
Date:
Subject: Re: Potential to_char localization bug