Tom Lane writes:
> 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.
postmaster -F should be used in this particular case. I'm not sure about
a general solution. I don't even know what the set of parameters for
checkpoint processes is or why they could usefully differ from the
postmaster's global settings.
> 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.
This is a bug. PG 7.1 wouldn't let this thing go through but with all the
changes made for the RESET ALL functionality (I think) this has snuck in.
My best guess is that this change was made to allow using
SetConfigOption() in PostgresMain() with options that are really
postmaster-global and are passed down to the backends. But AFAICS there
aren't any such options anymore.
> I wonder whether we should retire -o.
The only two postgres options which I would consider user-space are -F and
-S. The former also exists as a postmaster option, but that is newer and
people are used to the older form. The second one doesn't for obvious
reasons. With the config file this isn't so much of an issue any longer,
but people do use it.
(It's always been a goal of mine to merge the options that any of the
backend processes accept. The -S option really is the killer for that.)
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter