Re: pgsql start implies initdb = bad

[David Brownlee <abs%netbsd.org@localhost>]

2009/11/25 Jan Danielsson <jan.m.danielsson%gmail.com@localhost>:
> Hello,
>
> Â Today I was told that having rc.d/init.d scripts run initdb as a part
> of start (in case a database has not been initialized) is a seriously
> bad idea. I figured it was merely a precaution to guard against a
> theoretical problem.
>
> Â Interested parties should read this thread (it's actually really
> interesting to see the detective work being done):
> http://archives.postgresql.org/pgsql-hackers/2004-12/msg00479.php
>
> Â Apparently, there are at least two such examples, so it's not just a
> theoretical problem.
>
>[...suggested change to make start without db just display the initdb 
>command...]
>
> Â I don't think requiring administrators to run "/etc/rc.d/pgsql
> dbinit" (Or wherever it's kept) manually once after an install will ruin
> anyones pkgsrc experience. But I'm certain that anyone running in to a
> problem which stems from from dbinit being run implicitly from start
> will come down with a serious case of unhappiness.
>

Just to clarify - the issue here is the psql data directory being on a
soft or interruptable nfs mount, a restart when the mount is down
causing initdb to run on the local filesystem, and then the mount
coming back and psql scribbling 'new db data' over the production
database?

Running a database on an interruptable or soft mounted filesystem
manages to make using it on a normal nfs filesystem seem quite
sensible :)

I have a slight preference for leaving it as it is, maybe with an
optional pkgsrc variable which can be set to enable packages to auto
initdb (pkgsrc mysql works the same way for example), but I would not
complain too loudly if it was changed.