On 12/22/16 4:30 PM, Robert Haas wrote:
On Thu, Dec 22, 2016 at 4:41 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
On 12/22/16 4:20 AM, amul sul wrote:
• pg_background_detach : This API takes the process id and detach the
background process. Stored worker's session is not dropped until this
called.
When I hear "detach" I think that whatever I'm detaching from is going to
stick around, which I don't think is the case here, right? I'd suggest
pg_background_close() instead.
Uh, I think it is. At least in the original version of this patch,
pg_background_detach() leaves the spawned process running but says
that you don't care to read any results it may generate.
Oh, hmm. So I guess if you do that when the background process is idle
it's the same as a close?
I think we need some way to safeguard against accidental forkbombs for
cases where users aren't intending to leave something running in the
background. There's other reasons to use this besides spawning long
running processes, and I'd certainly want to be able to ensure the
calling function wasn't accidentally leaving things running that it
didn't mean to. (Maybe the patch already does this...)
--
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)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
