Re: One process per session lack of sharing

On Sun, Jul 17, 2016 at 3:04 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> On 7/14/16 12:34 AM, Craig Ringer wrote:
>> Starting with a narrow scope would help. Save/restore GUCs and the other
>> easy stuff, and disallow sessions that are actively LISTENing, hold
>> advisory locks, have open cursors, etc from being saved and restored.
>
> Along the lines of narrow scope... I wonder about allowing functions to
> execute in a separate process that communicates back to the main backend.
> That would allow unsafe languages to operate under a different OS user that
> was tightly restricted (ie: nobody/nogroup), but it could also allow for a
> pool of "function executors". Depending on how it was structured, it might
> also insulate the database from having to panic if a function crashed it's
> process.

You can do this sort of thing with background workers today. Just
create a parallel context and set the entrypoint to code that will
execute the guts of the function. Retrieve the results using a
shm_mq. With somewhat more work, you could have persistent background
workers that get reused for one function call after another instead of
being continually spun up and torn down. However, I suspect the IPC
costs would make this rather slow. Thomas Munro mentioned to me an
IPC facility called "doors" a while back which, if I understood him
correctly, is supposed to let you do a remote procedure call which
also transfers the current processes' time slice to the process on the
other end of the door. Maybe that would be faster, and fast enough;
or maybe not.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company