Re: pg_background contrib module proposal

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: amul sul <sulamul(at)gmail(dot)com>, Andrew Borodin <amborodin(at)acm(dot)org>, David Fetter <david(at)fetter(dot)org>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_background contrib module proposal
Date: 2017-01-08 03:20:41
Message-ID: 8bf1991f-b851-f32a-5359-30fcb0e506d6@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/22/16 4:30 PM, Robert Haas wrote:
> On Thu, Dec 22, 2016 at 4:41 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2017-01-08 03:35:59 Re: [PATCH] Rename pg_switch_xlog to pg_switch_wal
Previous Message Jim Nasby 2017-01-08 03:11:54 Re: merging some features from plpgsql2 project