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