Re: Storing a dynahash for an entire connection or

From: Neil Conway <neilc(at)samurai(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Dunstan <pgsql(at)tomd(dot)cc>, Volkan YAZICI <yazicivo(at)ttnet(dot)net(dot)tr>, Greg Mitchell <gmitchell(at)atdesk(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Storing a dynahash for an entire connection or
Date: 2006-11-27 22:45:00
Message-ID: 1164667500.23622.401.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-11-27 22:48:47 Re: doc patch for savepoints
Previous Message Devrim GUNDUZ 2006-11-27 22:31:22 Re: Shared pg_xlog directory/partition and warm standby