On Mon, 2009-12-07 at 13:03 +0900, Fujii Masao wrote:
> On Sun, Dec 6, 2009 at 2:49 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > Proposal is to split out the couple of lines in
> > readRecoveryCommandFile() that set important state and make it read in
> > an option block that can be used by caller. It would then be called by
> > both postmaster (earlier in startup) and again later by startup process,
> > as happens now. I want to do it that way so I can read file before we
> > create shared memory, so I don't have to worry about passing details via
> > shared memory itself.
>
> I agree with the proposal that postmaster reads the recovery.conf.
> Because this would enable all child processes to easily obtain the
> parameter values in that, like GUC parameters.
OK
> But I'm not sure why recovery.conf should be read separately by
> postmaster and the startup process. How about making postmaster
> read all of that for the simplification?
That sounds better but is more complex. We'd have to read in the file,
store in memory, then after shared memory is up put the data somewhere
so the startup process can read it. (Remember Windows).
What postgresql.conf already does is read file separately in each
process, so no data passing.
-- Simon Riggs www.2ndQuadrant.com