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  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список 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 по дате отправления:

Предыдущее
От: Ashutosh Sharma
Дата:
Сообщение: Re: [HACKERS] [PATCH] ALTER DEFAULT PRIVILEGES with GRANT/REVOKE ON SCHEMAS
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: [HACKERS] postgres_fdw bug in 9.6