On Tue, Jan 10, 2017 at 7:09 AM, Jim Nasby <jim.na...@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.na...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
