Skip site navigation (1) Skip section navigation (2)

Re: Storing a dynahash for an entire connection or

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Neil Conway <neilc(at)samurai(dot)com>
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:04:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Neil Conway wrote:
> On Mon, 2006-11-27 at 20:11 +0000, Tom Dunstan wrote:
>> 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?
> If you're content with your allocations never being automatically
> released for the duration of the session (which sounds like the behavior
> Greg would like, I'm guessing), you can just allocate the hash table in
> TopMemoryContext, in which case you wouldn't need to worry about the
> context of allocation vanishing beneath your feet.

Maybe I have misunderstood, but I don't see in this case how to 
determine that the cached data is still valid.



In response to


pgsql-hackers by date

Next:From: Joseph ShraibmanDate: 2006-11-27 22:08:45
Subject: doc patch for savepoints
Previous:From: Tom LaneDate: 2006-11-27 21:47:57
Subject: Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group