Bruce Momjian wrote:
> We could prevent the postmaster from starting unless they run pg_tune or
> if they have modified postgresql.conf from the default. Of course,
> that's pretty drastic.
If you're going to do that, then you may as well make the defaults
something that will perform reasonably well under the widest
circumstances possible and let the postmaster fail when it can't
acquire the resources those defaults demand.
What I'd do is go ahead and make the defaults something reasonable,
and if the postmaster can't allocate, say, enough shared memory pages,
then it should issue an error message saying not only that it wasn't
able to allocate enough shared memory, but also which parameter to
change and (if it's not too much trouble to implement) what it can be
changed to in order to get past that part of the initialization (this
means that the postmaster has to figure out how much shared memory it
can actually allocate, via a binary search allocate/free method). It
should also warn that by lowering the value, the resulting performance
may be much less than satisfactory, and that the alternative (to
increase SHMMAX, in this example) should be used if good performance
is desired.
That way, someone whose only concern is to make it work will be able
to do so without having to do a lot of experimentation, and will get
plenty of warning that the result isn't likely to work very well.
And we end up getting better benchmarks in the cases where people
don't have to touch the default config. :-)
--
Kevin Brown kevin@sysexperts.com
