Claudio Natoli said:
>
>> Looking at postmaster.c, my head started to spin a little. I think I
>> understood that exec case or not, by the time we get to BackendRun we
>> have already done all the fork/exec action. Have I read this
>> correctly?
>
> Yes. In the normal case, fork() then BackendRun.
Claudio Natoli <[EMAIL PROTECTED]> writes:
> Nice. Could perhaps also get it to do the ugly and oft repeated
> setitimer(ITIMER_PROF, &prof_itimer, NULL) and beos_backend_startup() bits,
> which currently contribute greatly in making the post-fork code unclear.
Good point.
> Flip you for it? :-)
> One thought I had was that there should be a common subroutine to do the
> stuff that a new postmaster subprocess needs to do immediately at
> startup. This includes setting IsUnderPostmaster, MyProcPid,
> on_exit_reset in the fork() case, reloading global variables in the
> exec() case, and m
Claudio Natoli <[EMAIL PROTECTED]> writes:
> If you like, I'll quickly provide a reversion of the BackendRun/Init split,
> and perhaps implement a "SubBootstrapMain"-ism... but this doesn't really
> help things overall. Is it at least a better point to start from?
I'd say think first and code late
Tom Lane wrote:
> What does SSDataBaseInit have to do with acquiring configuration
> parameters? (Answer: nothing.) Why is it being called here at all,
> and why only in the EXEC_BACKEND case? Sure can't figure
> that out from
> the uncommented code. Is it a good idea to do it? I rather doub
Claudio Natoli <[EMAIL PROTECTED]> writes:
>> It needs rewritten. The hacks inserted for ExecBackend have largely
>> destroyed the former structure (such as it was), and the lack of any
>> commentary added with said hacks didn't help. I am thinking
>> of tackling that rewrite once the dust has s
> It needs rewritten. The hacks inserted for ExecBackend have largely
> destroyed the former structure (such as it was), and the lack of any
> commentary added with said hacks didn't help. I am thinking
> of tackling that rewrite once the dust has settled.
Anything in particular?
With your
> Looking at postmaster.c, my head started to spin a little. I think I
> understood that exec case or not, by the time we get to BackendRun we
> have already done all the fork/exec action. Have I read this correctly?
Yes. In the normal case, fork() then BackendRun. In the EXEC_BACKEND case,
fo
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> (This code is getting rather intricate.
It needs rewritten. The hacks inserted for ExecBackend have largely
destroyed the former structure (such as it was), and the lack of any
commentary added with said hacks didn't help. I am thinking of tackling
th
Looking at postmaster.c, my head started to spin a little. I think I
understood that exec case or not, by the time we get to BackendRun we
have already done all the fork/exec action. Have I read this correctly?
(This code is getting rather intricate. A Readme file might be nice.
Just a thought)
> Claudio Natoli <[EMAIL PROTECTED]> writes:
> > So this means we'll have to pull relHash out of the shared FreeSpaceMap
> > structure and make it a variable in it's own right?
>
> Hm. The freespace.c code is relatively new and might not be jumping
> through all of the hoops it should be jumping
Claudio Natoli <[EMAIL PROTECTED]> writes:
> So this means we'll have to pull relHash out of the shared FreeSpaceMap
> structure and make it a variable in it's own right?
Hm. The freespace.c code is relatively new and might not be jumping
through all of the hoops it should be jumping through. My
> I'm not sure if you're confusing backend-local hashes with shared
> hashes, or hash control headers with the actual shared data. But
> the above is a false statement. DynaHashCxt is not shared.
No, wasn't confused over that. Was confused over something else though :-)
> Shared hashes are a
Claudio Natoli <[EMAIL PROTECTED]> writes:
> All the ShmemInitHash structures are allocated using DynaHashCxt.
I'm not sure if you're confusing backend-local hashes with shared
hashes, or hash control headers with the actual shared data. But
the above is a false statement. DynaHashCxt is not sha
Hi all,
I'm working on getting BackendFork converted to a fork/exec model, and have
hit the following wall.
All the ShmemInitHash structures are allocated using DynaHashCxt. Clearly,
this context is going to have to be shared across backends in the fork/exec
case, but I can't see a non-trivial w
15 matches
Mail list logo
