Re: Storing a dynahash for an entire connection or

Поиск
Список
Период
Сортировка
От Greg Mitchell
Тема Re: Storing a dynahash for an entire connection or
Дата
Msg-id 4575AF4D.2040106@atdesk.com
обсуждение исходный текст
Ответ на Re: Storing a dynahash for an entire connection or  (Neil Conway <neilc@samurai.com>)
Список 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
> 
> 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: old synchronized scan patch
Следующее
От: Tom Lane
Дата:
Сообщение: Re: old synchronized scan patch