Tom Lane wrote:
> Keep in mind that initdb doesn't currently *need* to put the datadir
> location into the config file.  It *will* need to do so if we separate
> config and data dirs.  Or at least, *somebody* will need to do so.
> It's not apparent to me how it simplifies life not to have initdb do it.
> Especially when there are other configuration items that initdb should
> or already does record: locale settings, database encoding.  

Is it possible for the database engine to properly deal with a
database when it is told to use a different database encoding than the
one the database was initdb'd with?

If it's not, then that suggests to me that the database encoding is
something that doesn't belong in the configuration file but rather in
some other place that is intimately tied with the database itself and
which is difficult/impossible to change, like perhaps a read-only
system table that gets created at initdb time.

> And we have already been talking about improving PG's self-tuning
> capability.  initdb would be the natural place to look around for
> information like available RAM and adjust the config-file settings
> like sort_mem accordingly.

I agree here, and since you're thinking of just putting the resulting
config file in the database data directory, then as a DBA I wouldn't
be terribly surprised by it ... especially if it came back with a
message that told me what it had done.

> If we do it the way I suggested (dump into the datadir, which is
> initially empty, same as always) then it cannot overwrite your existing
> config files.  Think of it as providing a suggested config file to
> compare against what you have.

There is one minor complication: what if there's an existing config
file in the target directory?

One use for initdb would be as a quick way to completely wipe the
database and start over (e.g., if the encoding were found to be
incorrect), but the config file that's already there could easily
contain a lot of customization that the administrator would want to
retain.  Which suggests that we should consider writing to a file
using a slightly different name (e.g., postgresql.conf.initdb), at
least in the event that a config file already exists in the target
directory.

Not sure what the overall right thing to do here is...


-- 
Kevin Brown                                           [EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Reply via email to