On Mon, Mar 17, 2014 at 1:41 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
After mulling over a few possible approaches, I came up with the
attached, which seems short and to the point.
Looks reasonable in principle. I didn't run through all the existing
On Mon, Mar 10, 2014 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas robertmh...@gmail.com wrote:
Hmm. So the problematic sequence of events is where a postmaster
child forks, and then exits without
Robert Haas robertmh...@gmail.com writes:
One option is to just change that function to also unmap the control
segment, and maybe rename it to dsm_detach_all(), and then use that
everywhere. The problem is that I'm not sure we really want to incur
the overhead of an extra munmap() during
On Mon, Mar 17, 2014 at 11:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
One option is to just change that function to also unmap the control
segment, and maybe rename it to dsm_detach_all(), and then use that
everywhere. The problem is that I'm not sure
Robert Haas robertmh...@gmail.com writes:
After mulling over a few possible approaches, I came up with the
attached, which seems short and to the point.
Looks reasonable in principle. I didn't run through all the existing
PGSharedMemoryDetach calls to see if there are any other places to
call
On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas robertmh...@gmail.com wrote:
The big picture here is that in the scenario being debated in the other
thread, exit() in a child process forked from a backend will execute that
backend's on_detach actions *even if the code had done on_exit_reset after
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas robertmh...@gmail.com wrote:
Hmm. So the problematic sequence of events is where a postmaster
child forks, and then exits without exec-ing, perhaps because e.g.
exec fails?
I've attempted a fix for this
On Mon, Mar 10, 2014 at 11:48 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas robertmh...@gmail.com wrote:
Hmm. So the problematic sequence of events is where a postmaster
child forks, and then exits without
Robert Haas escribió:
A related point that's been bugging me for a while, and has just
struck me again, is that background workers for which
BGWORKER_SHMEM_ACCESS is not passed probably ought to be detaching
shared memory (and DSMs). Currently, and since Alvaro originally
added the
On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that the DSM patch has introduced a whole new class of
failures related to the bug #9464 issue: to wit, any on_detach
actions registered in a parent process will also be performed when a
child process exits,
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that the DSM patch has introduced a whole new class of
failures related to the bug #9464 issue: to wit, any on_detach
actions registered in a parent process will also be
Hi,
On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
I don't think this can actually happen. There are quite a number of
things that would go belly-up if you tried to use dynamic shared
memory from the postmaster, which is why dsm_create() and
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
The big picture here is that in the scenario being debated in the other
thread, exit() in a child process forked from a backend will execute that
backend's on_detach actions *even if the code had done
On 2014-03-07 14:14:17 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com writes:
On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
The big picture here is that in the scenario being debated in the other
thread, exit() in a child process forked from a backend will execute that
On Fri, Mar 7, 2014 at 1:54 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I just noticed that the DSM patch has introduced a whole new class of
failures related to the bug #9464 issue: to
On Friday, March 7, 2014, Andres Freund and...@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
On 2014-03-07 12:09:45 -0800, Peter LaDow wrote:
On Friday, March 7, 2014, Andres Freund and...@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*
On Fri, Mar 7, 2014 at 12:17 PM, Andres Freund and...@2ndquadrant.com wrote:
Man. The point is that that the library code is carefully written to not
use exit() but _exit() after a fork failure, that's it.
I understand your point. I understand that in the case of the
postmaster we don't want
On Fri, Mar 7, 2014 at 12:17 PM, Andres Freund and...@2ndquadrant.com wrote:
Forking twice is ok as well, as long as you just use _exit() after the
fork. The thing is that you shouldn't run any nontrivial code in the
fork, as long as you're connected to the original environment (fd's,
memory
On Fri, Mar 7, 2014 at 12:55 PM, Peter LaDow pet...@gocougs.wsu.edu wrote:
Just to be clear, what do you mean by nontrivial code? Do you mean
C library calls, other than fork/exec/_exit?
I think I've answered my own question:
http://man7.org/linux/man-pages/man7/signal.7.html
The
20 matches
Mail list logo
