Re: [HACKERS] pg_background contrib module proposal

On Tue, Jan 10, 2017 at 7:09 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 1/9/17 7:22 AM, amul sul wrote:
>>
>> On Sun, Jan 8, 2017 at 8:50 AM, Jim Nasby <Jim.Nasby@bluetreble.com>
>> wrote:
>>>
>>>
>> [skipped...]
>>>
>>>
>>> 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...)
>>>
>>
>> Current pg_background patch built to the top of BackgroundSession code
>> take care of that;
>> user need to call pg_background_close() to gracefully close previously
>> forked background
>> worker.  Even though if user session who forked this worker exited
>> without calling
>> pg_background_close(), this background worked force to exit with following
>> log:
>>
>> ERROR:  could not read from message queue: Other process has detached
>> queue
>> LOG:  could not send on message queue: Other process has detached queue
>> LOG:  worker process: background session by PID 61242 (PID 61358)
>> exited with exit code 1
>>
>> Does this make sense to you?
>
>
> I'm specifically thinking of autonomous transactions, where you do NOT want
> to run the command in the background, but you do want to run it in another
> connection.
>
> The other example is running a command in another database. Not the same as
> the autonomous transaction use case, but once again you likely don't want
> that command running in the background.
>
> Put another way, when you launch a new process in a shell script, you have
> to do something specific for that process to run in the background.
>
> My concern here is that AIUI the only way to launch a bgworker is with it
> already backgrounded. That makes it much more likely that a bug in your code
> produces an unintended fork-bomb (connection-bomb?). That would be
> especially true if the function was re-entrant.
>
> Since one of the major points of bgworkers is exactly to run stuff in the
> background, while the parent connection is doing something else, I can
> certainly understand the default case being to background something, but I
> think it'd be good to have a simple way to start a bgworker, have it do
> something, and wait until it's done.
>
> Make sense?
>
I am not sure that I've understand this completely, but note that in
current pg_background design we simply launch worker once and feed the
subsequent queries using pg_background_run() api.

Regards,
Amul