Jim C. Nasby wrote:
> On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
> > We also decided to turn off the init script execution entirely. The DBAs
> > were more comfortable with a manual database startup for a production
> > machine anyway (this is the way they typically handle Oracle
On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
> We also decided to turn off the init script execution entirely. The DBAs
> were more comfortable with a manual database startup for a production
> machine anyway (this is the way they typically handle Oracle databases
> also). They ge
Am Freitag, 25. August 2006 16:54 schrieb Tom Lane:
> No, it doesn't. (The Red Hat RPMs in fact did that ... for about
> a week ... until I was told in no uncertain terms that we don't
> start unnecessary daemons by default.)
Well, there seem to be philosophical differences between the various op
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Freitag, 25. August 2006 16:20 schrieb Tom Lane:
>> It eats rather a lot of disk space for a package that might just be
>> getting loaded as part of a system install, with no likelihood of
>> actually being used.
> Wouldn't the system install start
Tom Lane <[EMAIL PROTECTED]> writes:
> Comments? Anyone see a better way?
Well the truly bullet-proof mechanism would be to check every data file on
every open. You could have a header with some kind of unique tag generated at
initdb time and the backend could ensure it matches the same tag in
Reinhard Max writes:
> Another flaw of the flag-file method is, that PGDATA might have been
> changed by the sysadmin between installing the RPM and calling the
> init script for the first time.
What problem do you see there? With either of these methods, a manual
change in PGDATA would requir
Am Freitag, 25. August 2006 16:20 schrieb Tom Lane:
> It eats rather a lot of disk space for a package that might just be
> getting loaded as part of a system install, with no likelihood of
> actually being used.
Wouldn't the system install start the init script at the end of the
installation pro
Tom Lane wrote:
We've seen more than one report of corruption of PG databases that
seemed to be due to the willingness of the RPM init script to run
initdb if it thinks the data directory isn't there. This is pretty
darn risky on an NFS volume, for instance, which might be offline
at the instant
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
>> I don't really want to remove the auto-initdb feature from the
>> script, because it's important not to drive away newbies by making
>> Postgres hard to start for the first time. But I think we'd better
>> think about ways to make it more bulletproo
> I don't really want to remove the auto-initdb feature from the
> script, because it's important not to drive away newbies by making
> Postgres hard to start for the first time. But I think we'd better
> think about ways to make it more bulletproof.
Why does initdb have to happen on startup? Wou
Am Freitag, 25. August 2006 15:19 schrieb Tom Lane:
> I don't really want to remove the auto-initdb feature from the script,
> because it's important not to drive away newbies by making Postgres
> hard to start for the first time. But I think we'd better think about
> ways to make it more bulletpr
We've seen more than one report of corruption of PG databases that
seemed to be due to the willingness of the RPM init script to run
initdb if it thinks the data directory isn't there. This is pretty
darn risky on an NFS volume, for instance, which might be offline
at the instant the script looks.
12 matches
Mail list logo
