| 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: | 456B60E6.5010307@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joseph Shraibman | 2006-11-27 22:08:45 | doc patch for savepoints |
| Previous Message | Tom Lane | 2006-11-27 21:47:57 | Re: Configuring BLCKSZ and XLOGSEGSZ (in 8.3) |