Glitch in handling of postmaster -o options

I have just noticed a flaw in the handling of "-o backend-options"
postmaster parameters. To wit: although these options will be passed
to all backends launched by the postmaster, they aren't passed to
checkpoint, xlog startup, and xlog shutdown subprocesses (everything
that goes through BootstrapMain). Since BootstrapMain doesn't
recognize the same set of options that PostgresMain does, this is
a necessary restriction. Unfortunately it means that checkpoint etc.
don't necessarily run with the same options as normal backends.

The particular case that I ran into is that I've been in the habit
of running test postmasters with "-o -F" to suppress fsync. Kernel
tracing showed that checkpoint processes were issuing fsyncs anyway,
and I eventually realized why: they're not seeing the command line
option.

While that's not a fatal problem, I could imagine *much* more serious
misbehavior from inconsistent settings of some GUC parameters. Since
backends believe that these parameters have PGC_POSTMASTER priority,
they'll accept changes that they probably oughtn't. For example,
postmaster -o --shared_buffers=N
will cause things to blow up very nicely indeed: backends will have
a value of NBuffers that doesn't agree with what the postmaster has.

I wonder whether we should retire -o. Or change it so that the
postmaster parses the given options for itself (consequently adjusting
its copies of GUC variables) instead of passing them on to backends
for parsing at backend start time.

regards, tom lane