On 03/07/2014 06:03 AM, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid. If it doesn't, then presumably we inherited the
atexit callback list, along with the value of MyProcPid, from some parent
backend process whose elbow we
On 03/07/2014 04:23 PM, Florian Weimer wrote:
On 03/07/2014 06:03 AM, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid. If it doesn't, then presumably we inherited the
atexit callback list, along with the value of MyProcPid,
On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid.
What are you proposing to do in that case? This is only one of the
failure cases of forking carelessly, right?
I think the only appropriate thing
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid.
What are you proposing to do in that case? This is only one of the
failure cases of forking
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 03/07/2014 04:23 PM, Florian Weimer wrote:
There's the PID reuse problem. Forking twice (with a delay) could end
up with the same PID as MyProcPid.
Not if the parent process is still running.
If the original parent backend is *not* still
On 03/07/2014 03:57 PM, Tom Lane wrote:
I think Florian's right that there's a risk there, but it seems pretty
remote, and I don't see any reliable way to detect the case anyhow.
(Process start time? Where would you get that from portably?)
I don't think there's a portable source for that.
On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 00:03:48 -0500, Tom Lane wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid.
What are you proposing to do in that case? This is
Florian Weimer fwei...@redhat.com writes:
On 03/07/2014 03:57 PM, Tom Lane wrote:
It's not a reason not to do something about the much larger chance of
this happening in a direct child process, which certainly won't have a
matching PID.
Indeed. Checking getppid() in addition might narrow
On 03/07/2014 04:10 PM, Tom Lane wrote:
Florian Weimer fwei...@redhat.com writes:
On 03/07/2014 03:57 PM, Tom Lane wrote:
It's not a reason not to do something about the much larger chance of
this happening in a direct child process, which certainly won't have a
matching PID.
Indeed.
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
No, I think it should do nothing. The coding pattern shown in bug #9464
seems perfectly reasonable and I think we should allow it.
I don't think it's a reasonable pattern run background processes that
Hi,
On 2014-03-07 10:24:31 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
No, I think it should do nothing. The coding pattern shown in bug #9464
seems perfectly reasonable and I think we should allow it.
I don't think
Sorry for the bit of top-posting, but I wanted to make some things
clear. Also, I wasn't subscribed to pgsql-hackers at the time this
thread began, so I apologize for the missing headers that might cause
threading issues.
I'm the submitter of bug #9464. Here's the background on what we are
Hi,
On 2014-03-07 09:50:15 -0800, Peter LaDow wrote:
Also, the on_exit_reset() does clear up the issue, and we have
implemented it as suggested in this thread (calling it immediately
after the fork() in the child). And Andres' keen eye noted we were
calling exit() after an exec() failure,
Back in commit 249a899f7, we introduced an atexit callback that forced
backend process cleanup to occur if some random backend plugin
(I'm looking at you, plperl and plpython) executed exit(). While that
seemed like a great safety feature at the time, bug #9464
On Fri, Mar 7, 2014 at 2:03 AM, Tom Lane t...@sss.pgh.pa.us wrote:
In the bug thread I proposed making atexit_callback check whether getpid()
still matches MyProcPid. If it doesn't, then presumably we inherited the
atexit callback list, along with the value of MyProcPid, from some parent
15 matches
Mail list logo
