Re: Proof-of-concept for initdb-time shared_buffers selection - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proof-of-concept for initdb-time shared_buffers selection
Date
Msg-id 1027.1059659001@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proof-of-concept for initdb-time shared_buffers selection  (Manfred Koizar <mkoi-pg@aon.at>)
List pgsql-hackers
Manfred Koizar <mkoi-pg@aon.at> writes:
> On Fri, 04 Jul 2003 15:29:37 -0400, Tom Lane <tgl@sss.pgh.pa.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?

Why would that be a good idea?  Seems to me it just offers a fresh
opportunity to do the wrong thing at every startup.  We'v had troubles
enough with problems that appear only when the postmaster is started by
hand rather than by boot script, or vice versa; this would just add
another unknown to the equation.

> 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.

Not unless their notion of a default .conf file includes a preinstalled
$PGDATA directory.  Under ordinary circumstances, initdb will get run
locally on the target machine, and should come up with a valid value.

            regards, tom lane

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: version mismatch message
Next
From: Tom Lane
Date:
Subject: Re: Another nasty pg_dump problem