Re: Proof-of-concept for initdb-time shared_buffers selection

On Fri, 04 Jul 2003 15:29:37 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>The attached patch shows how initdb can dynamically determine reasonable
>shared_buffers and max_connections settings that will work on the
>current machine.

Can't this be done on postmaster startup? I think of two GUC
variables where there is only one today: min_shared_buffers and
max_shared_buffers. If allocation for the max_ values fails, the
numbers are decreased in a loop of, say, 10 steps until allocation
succeeds, or even fails at the min_ values.

The actual values chosen are reported as a NOTICE and can be inspected
as readonly GUC variables.

This would make the lives easier for the folks trying to come up with
default .conf files, e.g.
min_shared_buffers = 64
max_shared_buffers = 2000
could cover a fairly large range of low level to mid level machines.

A paranoid dba, who doesn't want the postmaster to do unpredictable
things on startup, can always set min_xxx == max_xxx to get the
current behaviour.

Servus
Manfred