From: | "Len Morgan" <len-morgan(at)crcom(dot)net> |
---|---|
To: | <pgsql-general(at)hub(dot)org> |
Subject: | Re: initdb and "exit_nicely"... |
Date: | 2000-05-18 11:48:30 |
Message-ID: | 002001bfc0be$fdbe7560$0908a8c0@H233.bstx.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>> A slightly more reasonable example is where the admin has already
>> inserted his own pg_hba.conf in the directory; would be nice if initdb
>> didn't overwrite it (nor delete it on failure), but I'm not sure it's
>> worth the trouble.
>
>I am inclined to leave it as is too. I can imagine many bug reports if
>that directory is not flushed on failure.
>
I'm no expert on shell scripts, but couldn't the current initdb script be
wrapped by something like:
if exists PG_DATA directory {
create a file listing all of the filenames currently in the directory
called "pre-existing.files"
}
current initdb script ...
if exists "pre-existing.files" {
delete all files in PG_DATA dir except those in pre-existing.files
}
The reason that IMHO this deserves a little consideration (i.e., doing it at
all rather than just saying "Don't store any files in PG_DATA") is that
RedHat based rpm installations create the postgres superuser account as part
of the process and set the home directory for this user to PG_DATA. I do a
lot of remote administration of Postgresql systems and frequently telnet
into them as user postgres which leaves me in the PG_DATA directory. I'll
upload a file or two and not really think about where I am.
I don't personally know what the effect of already having the postgres user
account set up with a different home directory does to an RPM. Perhaps the
rpm maintainer could create the postgres user account with a home directory
of /home/postgres instead of PG_DATA?
Anyway, my 0.02 dollar's worth.
len morgan
From | Date | Subject | |
---|---|---|---|
Next Message | Jeffery Collins | 2000-05-18 12:29:49 | Passing arguments to and INDEX function. |
Previous Message | Michael Meskes | 2000-05-18 07:56:25 | Re: Performance |