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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Koizar <mkoi-pg(at)aon(dot)at>
Cc: pgsql-hackers(at)postgreSQL(dot)org, pgsql-patches(at)postgreSQL(dot)org
Subject: Re: Proof-of-concept for initdb-time shared_buffers selection
Date: 2003-07-31 13:43:21
Message-ID: 1027.1059659001@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> 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?

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-07-31 13:58:31 Re: version mismatch message
Previous Message Andreas Pflug 2003-07-31 12:39:21 Re: followup on previous

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2003-07-31 14:05:25 Re: Check for failed memory allocations in libpq
Previous Message Tom Lane 2003-07-31 13:37:44 Re: [Fwd: Re: ruleutils with pretty-print option]