Re: on_exit_reset fails to clear DSM-related exit actions

Поиск
Список
Период
Сортировка
От Peter LaDow
Тема Re: on_exit_reset fails to clear DSM-related exit actions
Дата
Msg-id CAN8Q1EedGN_a96x6m_-oeVhRgB19Ei5nYddt=HfEiYOdX5fu8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: on_exit_reset fails to clear DSM-related exit actions  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: on_exit_reset fails to clear DSM-related exit actions  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On Friday, March 7, 2014, Andres Freund <andres@2ndquadrant.com> wrote:
If the third party library is suitably careful it will only use fork()
and then exec() or _exit(), otherwise there are other things that'll be

But that is not possible* in our case of trying to spawn an asynchronous backgound process. The goal here is for the extension to spawn the process and return immediately. If we exec in the first level child, and immediately return, who reaps the child when done?

This is why we fork twice and exit in the first level child so that the extension can reap the first.

Unless Postgres happily reaps all children perhaps through a SIGCHLD handler?

(* I suppose we could exec a program that itself forks/execs a background process. But that is essentially no different than what we are doing now, other than trying to meet this fork/exec/_exit requirement. And that's fine if that is to be the case. We just need to know what it is.)
  
Both perl and glibc seem to do just that in system() btw...

I don't know about Perl, but system is blocking. What if you don't want to wait for the child to exit?

Pete 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: on_exit_reset fails to clear DSM-related exit actions
Следующее
От: Andres Freund
Дата:
Сообщение: Re: on_exit_reset fails to clear DSM-related exit actions