| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <AMatveev(at)bitec(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: One process per session lack of sharing |
| Date: | 2016-07-17 19:04:38 |
| Message-ID: | 8524e1e2-9d77-8660-54c2-b61613c8b867@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-07-17 19:12:48 | Re: One process per session lack of sharing |
| Previous Message | Jan Wieck | 2016-07-17 18:55:20 | Re: A Modest Upgrade Proposal |