Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
От | Jan de Visser |
---|---|
Тема | Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? |
Дата | |
Msg-id | 3214480.tvNNvqpQkW@coyote обсуждение исходный текст |
Ответ на | Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? (<david@andl.org>) |
Ответы |
Re: Does a call to a language handler provide a context/session, and somewhere to keep session data?
Re: Does a call to a language handler provide a context/session, and somewhere to keep session data? |
Список | pgsql-general |
On March 8, 2016 12:18:08 AM david@andl.org wrote: > From: pgsql-general-owner@postgresql.org > [mailto:pgsql-general-owner@postgresql.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
В списке pgsql-general по дате отправления: