Re: [HACKERS] pg_background contrib module proposal
От | amul sul |
---|---|
Тема | Re: [HACKERS] pg_background contrib module proposal |
Дата | |
Msg-id | CAAJ_b957mMxCppG=Y+2WXmfwyJSq6Hdp1PsiyyKVGBnWhpUoWA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_background contrib module proposal (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
Ответы |
Re: [HACKERS] pg_background contrib module proposal
|
Список | pgsql-hackers |
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? Regards, Amul
В списке pgsql-hackers по дате отправления: