Re: initdb profiles - Mailing list pgsql-hackers

From Steve Atkins
Subject Re: initdb profiles
Date
Msg-id 20050909173002.GB16154@gp.word-to-the-wise.com
Whole thread Raw
In response to Re: initdb profiles  (Andrew - Supernews <andrew+nonews@supernews.com>)
List pgsql-hackers
On Thu, Sep 08, 2005 at 08:29:38PM -0000, Andrew - Supernews wrote:
> On 2005-09-08, Peter Eisentraut <peter_e@gmx.net> wrote:
> > Andrew - Supernews wrote:
> >> Running initdb behind the scenes is a proven dangerous practice
> >
> > Please elaborate.
> 
> Example instance:
> http://archives.postgresql.org/pgsql-hackers/2004-12/msg00851.php
> 
> More generally, you risk running initdb and doing a normal database
> startup despite missing filesystems (assuming your db is substantial
> and important enough that you don't keep in it /var or /usr). There are
> a number of ways that this can bite you, whether due to thinking that
> the database is up when it really isn't usable, or subsequently mounting
> over the new data dir, or any number of other potential issues.
> 
> A missing data directory on startup should mean "something is wrong", not
> "oh look, I'll run initdb and start up anyway".

I think we read entirely different things into "behind the scenes".

I have an installer script that's run to install a software
package. It runs an initdb to create the database it uses behind the
scenes.

Running initdb as part of an installation process is a very different
scenario to randomly running it whenever you think something may not
be quite right (although that is the pattern used by many other
daemon startup scripts on the OS in question, so it's at least
consistent).

Cheers, Steve


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: initdb profiles
Next
From: Bruce Momjian
Date:
Subject: Re: PostgreSQL from source using MinGW