Thread: Another POC initdb patch

Hi all,

In addition to Tom's patch, this patch asks tuning parameters right away,
while doing initdb. I have also changed the notice displayed after initdb is
done.

Just an attempt to make defaults user friendly. I would also like to add other
paramters to this approach, like fsync and random_page_cost but first I
thought others should have look at these.

And one more thing, can we get all the parameters in postgresql.conf to follow
similar units? Some settings aer in 8KB pages, some in bytes etc. Can we haev
all of them to follow say MB or KB?

I tried but guc.h and guc.c were bit too much to be gulped at one go. I will
try again.

 Shridhar

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.

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

            regards, tom lane

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