On March 8, 2016 12:18:08 AM david@xxxxxxxx wrote: > From: pgsql-general-owner@xxxxxxxxxxxxxx > [mailto:pgsql-general-owner@xxxxxxxxxxxxxx] On Behalf Of John R Pierce > > > > Yes, I was aware of GD and SD. My question is about what facilities Postgres > provides for implementing such a thing. Where is the proper place for the > root of the SD/GD? What does an implementation use to determine that two > calls belong to the same session? > > the process ID is unique for each active session. of course, the OS can > recycle a PID when a process/connection terminates > > [dmb>] Thanks for the idea, but I’m wary of using PID for that purpose. > > [dmb>] In the Python implementation the GD appears to just be stored as a > simple variable at file scope in the DLL. Would I be right in saying that > the language handler DLL is loaded exactly once for each session (when the > language is first used)? If so, then any unique identifier allocated in > PG_init (such as a GUID or timestamp or counter) would seem to serve the > purpose. I just wondered if there was something clever I hadn’t found out > about yet. > 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-land code (which includes language handlers). So I think your problem goes away once you realize that all the data you have is tied to a single connection anyway. You cannot use multi-threaded code (which touches the database) in language handlers or other "plug-in" code. 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
