From: | Greg Mitchell <gmitchell(at)atdesk(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Storing a dynahash for an entire connection or |
Date: | 2006-12-05 17:41:33 |
Message-ID: | 4575AF4D.2040106@atdesk.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Ok, I implemented the cache in the TopMemoryContext and then stored the
pointer in a global static * in the type's .c file.
Now, I'm wondering if there is way I can effectively do a LISTEN on a
given event such that when the table that represents the map is updated,
a trigger could call NOTIFY xyz; ? Upon receiving this event, each
connection should refresh its cache.
Ideas?
Thanks,
Greg
Neil Conway wrote:
> On Mon, 2006-11-27 at 17:04 -0500, Andrew Dunstan wrote:
>> Maybe I have misunderstood, but I don't see in this case how to
>> determine that the cached data is still valid.
>
> Well, I was saying that if you want to cache something for the duration
> of the current session, checking for the validity of the context of
> allocation is moot, since you can just use a long-lived context.
>
> If you want to cache stuff for the duration of a transaction, one
> technique would be to maintain the cache in a child of TopMemoryContext,
> stamp the cache data with the XID that created it, and then use the XID
> to decide when to invalidate cached data.
>
> Note that regardless of the memory context that is used, implementing
> correct transactional behavior is non-trivial: the int2 -> text mapping
> will still be incorrect in the face of changes to the mapping table by
> your own transaction (or another committed txn, in the case of read
> committed). From Greg's description I guessed that a session-length
> cache was what he needed anyway...
>
> -Neil
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-12-05 17:56:18 | Re: old synchronized scan patch |
Previous Message | Jeff Davis | 2006-12-05 17:39:07 | Re: old synchronized scan patch |