From: pgsql-general-owner@postgresql.org [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Jan de Visser
One thing that's probably key here is that pgsql isn't multi-threaded.
Individual connections are handled by forked backends, which share a shared- memory cache that's not accessible by
SQL-landcode (which includes language handlers). So I think your problem goes away once you realize that all the data
youhave is tied to a single connection anyway.
[dmb>]
[dmb>] Thanks. Yes, I knew that. My problem is a strategy to start up the language engine once (per session), load
stufffrom the database once, and then keep the per-call cost as low as possible. I know that palloc() memory goes away;
thatit has a lifetime longer than a function invocation and should span a recursive function call, but definitely not
longerthan a transaction. So I need to get some memory per session and keep a pointer to it per session (which it seems
isper process).
You cannot use multi-threaded code (which touches the database) in language handlers or other "plug-in" code.
[dmb>] That's good -- I hate threads. I've never been able to figure out how to test them adequately. No loss there.
Also, trying to outsmart the db engine's cache by building your own is usually an exercise in futility and often
counter-productive.I speak from experience :-P
[dmb>] Isn't cache invalidation the second hardest thing in computing (after naming things)?
[dmb>] Seems like DLL static memory with allocation from process memory (or even malloc()) is "the simplest thing that
couldpossibly work".
Regards
David M Bennett FACS
Andl - A New Database Language - andl.org