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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to