Re: on_exit_reset fails to clear DSM-related exit actions

From: Peter LaDow <petela(at)gocougs(dot)wsu(dot)edu>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: on_exit_reset fails to clear DSM-related exit actions
Date: 2014-03-07 20:09:45
Message-ID: CAN8Q1EedGN_a96x6m_-oeVhRgB19Ei5nYddt=HfEiYOdX5fu8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Friday, March 7, 2014, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-03-07 20:17:25 Re: on_exit_reset fails to clear DSM-related exit actions
Previous Message Robert Haas 2014-03-07 19:40:31 Re: on_exit_reset fails to clear DSM-related exit actions