Re: [HACKERS] pg_background contrib module proposal
От | Jim Nasby |
---|---|
Тема | Re: [HACKERS] pg_background contrib module proposal |
Дата | |
Msg-id | 8bf1991f-b851-f32a-5359-30fcb0e506d6@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_background contrib module proposal (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] pg_background contrib module proposal
|
Список | pgsql-hackers |
On 12/22/16 4:30 PM, Robert Haas wrote: > On Thu, Dec 22, 2016 at 4:41 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: >> On 12/22/16 4:20 AM, amul sul wrote: >>> • pg_background_detach : This API takes the process id and detach the >>> background process. Stored worker's session is not dropped until this >>> called. >> >> When I hear "detach" I think that whatever I'm detaching from is going to >> stick around, which I don't think is the case here, right? I'd suggest >> pg_background_close() instead. > > Uh, I think it is. At least in the original version of this patch, > pg_background_detach() leaves the spawned process running but says > that you don't care to read any results it may generate. > 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...) -- 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)
В списке pgsql-hackers по дате отправления: