On Mon, 2 Aug 1999, Tom Lane wrote:
> Great stuff, Michael. I think by the time most of us got to the point
> of contributing much to Postgres, we'd forgotten the little glitches
> we hit on the first try. Cleaning up these issues is definitely
> worthwhile, and I am glad to see you willing to help out.
>
> Thomas already gave good responses about the technical issues,
> but I have one point to add:
>
> >> - The aforementioned shared memory problem was distressing. Thank God
> >> somebody else had just encountered it. Is there any better way to
> >> trap for that? Should the default number of backends be made something
> >> less than 32 so that the "common setting" of 1 meg will be safe? Am I
> >> being too wimpy?
>
> > This is the first release where the shared memory size was actually
> > being calculated correctly. The numbers used pretty much match the
> > theoretical (but incorrectly calculated) maximum limits in previous
> > releases, but the calculated number is bigger and a few OSes seem to
> > cough. Your OS is being wimpy imho, but the workaround is pretty easy.
>
> Actually, when we set the default MAXBACKENDS to 32 for 6.5, it was
> done specifically to ensure that the default shared mem block size would
> stay under a meg. (The equivalent setting in 6.4 was 64 backends.)
> But I guess various data structures changed a little bit after that
> time, and we ended up on the wrong side of the breakpoint without
> thinking about it.
>
> Should we cut the default MAXBACKENDS some more, or just try to
> document the issue better?
My opinion...cut it back to 16 and document. Reason: those new won't hit
the problem, and those that have started to use it in "more production
environments" will have started to look into performance tuning, and most
likely have at least scan'd thruogh the postmaster man page (and will have
seen the -B option)...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org