On Sun, Jul 17, 2016 at 3:04 PM, Jim Nasby <jim.na...@bluetreble.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
