Re: One process per session lack of sharing

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.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461