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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers