Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?

On March 8, 2016 12:18:08 AM david(at)andl(dot)org wrote:
> From: pgsql-general-owner(at)postgresql(dot)org
> [mailto:pgsql-general-owner(at)postgresql(dot)org] 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