On Tue, 2003-02-11 at 13:01, Tom Lane wrote:
> "Jon Griffin" <jon@jongriffin.com> writes:
> > So it appears that linux at least is way above your 8 meg point, unless I
> > am missing something.
>
> Yeah, AFAIK all recent Linuxen are well above the range of parameters
> that I was suggesting (and even if they weren't, Linux is particularly
> easy to change the SHMMAX setting on). It's other Unixoid platforms
> that are likely to have a problem. Particularly the ones where you
> have to rebuild the kernel to change SHMMAX; people may be afraid to
> do that.
The issue as I see it is:
Better performing vs. More Compatible Out of the box Defaults.
Perhaps a compromise (hack?):
Set the default to some default value that performs well, a value we all
agree is not too big (16M? 32M?). On startup, if the OS can't give us
what we want, instead of failing, we can try again with a smaller
amount, perhaps half the default, if that fails try again with half
until we reach some bottom threshold (1M?).
The argument against this might be: When I set shared_buffers=X, I want
X shared buffers. I don't want it to fail silently and give me less than
what I need / want. To address this we might want to add a guc option
that controls this behavior. So we ship postgresql.conf with 32M of
shared memory and auto_shared_mem_reduction = true. With a comment that
the administrator might want to turn this off for production.
Thoughts?
I think this will allow most uninformed users get decent performing
defaults as most systems will accommodate this larger value.
