On Mon, Mar 17, 2014 at 1:41 PM, Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 dsm_detach_all, but
On Mon, Mar 17, 2014 at 11:32 AM, Tom Lane wrote:
> Robert Haas 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 ov
Robert Haas 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 every backend exit, ju
On Mon, Mar 10, 2014 at 11:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas 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 att
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 faci
On Mon, Mar 10, 2014 at 11:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas 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 att
Robert Haas writes:
> On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas 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 case. The attached patch makes
> tes
On Fri, Mar 7, 2014 at 2:40 PM, Robert Haas 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
>> the fork*.
>
>
On Fri, Mar 7, 2014 at 12:55 PM, Peter LaDow 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 'Async-signal-safe functions'
On Fri, Mar 7, 2014 at 12:17 PM, Andres Freund 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 mappings and so fort
On Fri, Mar 7, 2014 at 12:17 PM, Andres Freund 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 to invoke behavior tha
On 2014-03-07 12:09:45 -0800, Peter LaDow wrote:
> On Friday, March 7, 2014, Andres Freund 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 t
On Friday, March 7, 2014, Andres Freund 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
On Fri, Mar 7, 2014 at 1:54 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane 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 paren
On 2014-03-07 14:14:17 -0500, Tom Lane wrote:
> Andres Freund 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_deta
Andres Freund 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_exit_reset afte
Hi,
On 2014-03-07 13:54:42 -0500, Tom Lane wrote:
> Robert Haas 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 dsm_attach()
> > both
Robert Haas writes:
> On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane 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 proces
On Fri, Mar 7, 2014 at 10:04 AM, Tom Lane 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, because nothing ha
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, because nothing has been added to on_exit_reset
to prevent that. It seems l
21 matches
Mail list logo
