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?
--
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
