Re: Another POC initdb patch - Mailing list pgsql-patches

From Shridhar Daithankar
Subject Re: Another POC initdb patch
Date
Msg-id 200307071215.59227.shridhar_daithankar@nospam.persistent.co.in
Whole thread Raw
In response to Re: Another POC initdb patch  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
On Sunday 06 July 2003 20:55, Tom Lane wrote:
> Shridhar Daithankar <shridhar_daithankar@persistent.co.in> writes:
> > In addition to Tom's patch, this patch asks tuning parameters right away,
> > while doing initdb.
>
> Sorry, there is zero chance of putting any interactivity into initdb.
> Most RPM installations run it from the RPM install script and would be
> unable to cope with this.

Hmm.. If distro. vendors can put a wrapper of service script around it on
their own, how much difficult it is to modify initdb to revert back to
original behaviour?

I think it would be fair on linux distro. vendors part if they decide to put a
reasonable default for shared_buffers. Unlike postgresql community, they
don't haev to worry about OS protability because they know that it is going
to run on only linux.

I mailed mandrake long time back, requesting a config file for service script
where it would allow to specify database location. No reply.

> I disagree with the concept of expecting someone to supply useful values
> at install time anyway, since a newbie is the *least* likely to have any
> idea what to say at that time.  Heck, the experts can hardly agree on
> what to use ...

Whatever user says might not be the best or optimum but will be likely to be
much better than 64.

I agree that this is not part of rpm philosophy. Install and configure is only
followed by debian IIRC.

Furthermore this could take care of user complains that postgresql does not
have reasonable defaults. Problems with such approach w.r.t. linux distro.s
aren't exactly impossible to solve. May be we could add it to release notes,
for their convinience.

Another proposal is to take out everything interactive I put it in patch,
write another shell script, that would tune postgresql.conf, like the
configuration wizard you suggested.

No matter where it goes, users would be very happy to have a tool which hand
holds them to a reasonanly working config file and points to right
documentation thereafter.

 Shridhar


pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Proof-of-concept for initdb-time shared_buffers selection
Next
From: Bruce Momjian
Date:
Subject: fix for new SUSET GUC variables