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,
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
doing
Hi,
On 2014-03-07 10:24:31 -0500, Tom Lane wrote:
> Andres Freund 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 rea
Andres Freund 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
> aren't managed
On 03/07/2014 04:10 PM, Tom Lane wrote:
Florian Weimer 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 ad
Florian Weimer 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 things down f
On 2014-03-07 09:49:05 -0500, Tom Lane wrote:
> Andres Freund 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 o
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. O
Heikki Linnakangas 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 running, then run
Andres Freund 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 carelessly, right?
No, I
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 wo
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, fro
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 sh
On Fri, Mar 7, 2014 at 2: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 who
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
http://www.postgresql.org/message-id
15 matches
Mail list logo
