Claudio Natoli <claudio.natoli@memetrics.com> 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 settled.
> Anything in particular?
> With your SubPostmaster suggestion, the split of BackendRun (ne:
> BackendFork) and BackendInit could now be undone (and I had a TODO item to
> ask the list if such a reversion was desirable, and provide said patch)...
I had intended to do that, but in general it seems like there's more
jumping around now. Here's an example that annoyed me recently when
I was looking at IsUnderPostmaster uses. At about line 370 of
bootstrap.c:
/* Acquire configuration parameters */ if (IsUnderPostmaster) {
#ifdef EXEC_BACKEND read_nondefault_variables(); read_backend_variables(backendID,NULL);
SSDataBaseInit(xlogop);
#endif } else ProcessConfigFile(PGC_POSTMASTER);
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 doubt it
--- that routine does on_exit_reset, which would lose any previously
registered exit callbacks, which is something that should only happen
immediately after fork(), not as far down in BootstrapMain as this is
being done.
But Andrew's complaint already had some merit even before this work
started. We probably ought to rear back and contemplate the overall
structure of postmaster.c and postgres.c, and see what we can do to make
it more comprehensible. I don't have any immediate thoughts about what
to do, just a bee in my bonnet that it needs to be done. Any ideas?
regards, tom lane
