Thread: initdb and "exit_nicely"...
I believe there is a bug, or at least a not very nice feature in initdb. If initdb does not succeed, it attempts to "exit_nicely". By default this involved deleting the $PGDATA directory!! So if you have put other things in you $PGDATA directory or (as in my case) you attempt to create a database in an existing directory that contains lots of stuff that you really, really wanted to keep, and initdb fails, initdb very "nicely" deletes them for you if it fails. It seems like it would be a whole lot "nicer" if initdb only deleted the files that it attempted to create OR if the default was not to delete anything. In any case, I have changed the default on my installation to NEVER "clean up" for me. Jeff Collins
Jeffery Collins writes: > It seems like it would be a whole lot "nicer" if initdb only deleted > the files that it attempted to create OR if the default was not to > delete anything. Okay, I could go for the former. What do others think? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
>> It seems like it would be a whole lot "nicer" if initdb only deleted
>> the files that it attempted to create OR if the default was not to
>> delete anything.
> Okay, I could go for the former. What do others think?
It'd be a bit of a pain but I can see the problem. You certainly
shouldn't delete the $PGDATA directory itself unless you created it,
IMHO. Doing more than that would imply that initdb's cleanup
function would have to know the list of files/subdirectories that
normally get created during initdb, so as to remove only those and
not anything else that might be lying around in the directory.
That'd be a considerable maintenance headache since most of said files
are not created directly by the script...
BTW, what about collisions? Suppose the reason the initdb fails
is that there's already a (bogus) pg_log, or some such --- is
the script supposed to know not to delete it? That strikes me
as way too difficult, since now the script has to know not only
which files get created but exactly when.
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.
Something that would be a lot simpler is to refuse to run at all
if the $PGDATA dir exists and is nonempty ;-)
regards, tom lane
> 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. -- Bruce Momjian | http://www.op.net/~candle pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>> 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
Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> >> It seems like it would be a whole lot "nicer" if initdb only deleted
> >> the files that it attempted to create OR if the default was not to
> >> delete anything.
>
> > Okay, I could go for the former. What do others think?
>
> It'd be a bit of a pain but I can see the problem. You certainly
> shouldn't delete the $PGDATA directory itself unless you created it,
> IMHO. Doing more than that would imply that initdb's cleanup
> function would have to know the list of files/subdirectories that
> normally get created during initdb, so as to remove only those and
> not anything else that might be lying around in the directory.
> That'd be a considerable maintenance headache since most of said files
> are not created directly by the script...
>
I agree this would be a pain. After thinking about it, I think the best
approach is to do one or both of the following:
- Change the default to not delete $PGDATA.
- Prompt the user for confirmation before deleting $PGDATA.
Anything else sounds like a pain in the *ss and very error prone.
Jeff Collins
"Len Morgan" <len-morgan@crcom.net> writes:
> 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.
To be blunt, that's *incredibly* brain dead. The contents of the PGDATA
directory are way too critical to be the account's home directory. The
correct fix for this is to change the way the RPM sets up the account.
I don't think we are doing anyone a service if we tweak initdb in a way
that will make it slightly safer to keep random files in PGDATA. You
shouldn't do it anyway, and modifying initdb to make it look like you
can will only increase the risk of people accidentally screwing up their
installation.
regards, tom lane
On Thu, May 18, 2000 at 11:05:58AM -0400, Tom Lane wrote:
> "Len Morgan" <len-morgan@crcom.net> writes:
> > 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.
>
> To be blunt, that's *incredibly* brain dead.
Does Red Hat actually make the _data_ directory the home? Debian avoids
this by making /var/lib/postgres the home, and data/ under that the PGDATA
directory. It sure doesn't seem a good idea to be using PGDATA as a home
directory.
--
Andrew Sullivan Computer Services
<sullivana@bpl.on.ca> Burlington Public Library
+1 905 639 3611 x158 2331 New Street
Burlington, Ontario, Canada L7R 1J4
I wrote: > Jeffery Collins writes: > > It seems like it would be a whole lot "nicer" if initdb only deleted > > the files that it attempted to create OR if the default was not to > > delete anything. > > Okay, I could go for the former. What do others think? Here's a patch that might do what you need but I'm somewhat suspicious of this situation. Recycling an old PGDATA directory is not supported, in facts it's explicitly prevented with certain checks in initdb. So apparently you precreated the data directory and put "interesting things" of your own in it, which is not necessarily something that's encouraged either. It does make sense to leave the PGDATA directory and only clean out the _contents_ on failure, that is, use `rm -rf $PGDATA/*' instead of `rm -rf $PGDATA' but I doubt that that can be done portably. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Attachment
Tom Lane writes: > Something that would be a lot simpler is to refuse to run at all > if the $PGDATA dir exists and is nonempty ;-) Yes, why not? Initialize first, customize second. I thought initdb provides a default pg_hba.conf file etc. so there's little to no reason to do it the other way around. -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
At 11:35 AM 18-05-2000 -0400, Andrew Sullivan wrote: >On Thu, May 18, 2000 at 11:05:58AM -0400, Tom Lane wrote: >> "Len Morgan" <len-morgan@crcom.net> writes: >> > 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. >> >> To be blunt, that's *incredibly* brain dead. > >Does Red Hat actually make the _data_ directory the home? Debian avoids >this by making /var/lib/postgres the home, and data/ under that the PGDATA >directory. It sure doesn't seem a good idea to be using PGDATA as a home >directory. I dunno, AFAIK it didn't seem to do such a thing. If it did, it should be changed- very dangerous. Files may be uploaded or written to unfortunate places. I think initdb should NOT touch existing PGDATA directories. Let the user take the responsibility for rm -rf or moving/renaming. If PGDATA exists it should leave it, or at worst rename it to PGDATA.old.1 (increasing number or maybe datetime). This way less badness is likely to happen. Sure it's a bit inconvenient to have to delete stuff yourself, but compared to accidentally deleting a whole bunch of stuff, I think mv or rm are easy (in fact I bet some people have found them too easy ;) ). Cheerio, Link.
On Tue, 23 May 2000, Lincoln Yeoh wrote: > At 11:35 AM 18-05-2000 -0400, Andrew Sullivan wrote: > >On Thu, May 18, 2000 at 11:05:58AM -0400, Tom Lane wrote: > >> "Len Morgan" <len-morgan@crcom.net> writes: > >> > 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. > >> To be blunt, that's *incredibly* brain dead. > >Does Red Hat actually make the _data_ directory the home? Debian avoids > >this by making /var/lib/postgres the home, and data/ under that the PGDATA > >directory. It sure doesn't seem a good idea to be using PGDATA as a home > >directory. > I dunno, AFAIK it didn't seem to do such a thing. If it did, it should be > changed- very dangerous. Files may be uploaded or written to unfortunate > places. PostgreSQL 7.0 RPMs place home for postgres to be /var/lib/pgsql, and PGDATA is /var/lib/pgsql/data. I just _look_ stupid. :-) The postgres user's home was changed for 7.0 just exactly because of the bad choice of home being PGDATA. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Tue, 23 May 2000, Lamar Owen wrote: > PostgreSQL 7.0 RPMs place home for postgres to be /var/lib/pgsql, and PGDATA is > /var/lib/pgsql/data. I just _look_ stupid. :-) The postgres user's home was > changed for 7.0 just exactly because of the bad choice of home being PGDATA. Well, maybe I more than just look stupid. I of course meant 'PGDATA was changed for 7.0 just exactly because....'. Long day. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lincoln Yeoh <lylyeoh@mecomb.com> writes:
> I think initdb should NOT touch existing PGDATA directories. Let the user
> take the responsibility for rm -rf or moving/renaming. If PGDATA exists it
> should leave it, or at worst rename it to PGDATA.old.1 (increasing number
> or maybe datetime).
Well, we can't quite do that, because PGDATA may very well be a
subdirectory of a root-owned directory --- so initdb *must* be willing
to cope with the case that PGDATA directory has been created for it
by root.
The idea I suggested a couple of days ago was that initdb should refuse
to run if PGDATA exists and is nonempty. Sound reasonable?
regards, tom lane
At 11:51 PM 23-05-2000 -0400, Tom Lane wrote: > >The idea I suggested a couple of days ago was that initdb should refuse >to run if PGDATA exists and is nonempty. Sound reasonable? Yep. Easy to understand and easier to code too :). Cheerio, Link.
Tom Lane writes: > The idea I suggested a couple of days ago was that initdb should refuse > to run if PGDATA exists and is nonempty. Sound reasonable? Okay, let's do that. How do you find out if a directory is empty? The best way I could think of is this: test x"`ls -A "$PGDATA"`" = x Are we talking 7.0.1 material, btw? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
> How do you find out if a directory is empty?
Good question.
> The best way I could think of is this:
> test x"`ls -A "$PGDATA"`" = x
The embedded quotes might confuse some shells, no? Perhaps better
CONTENTS=`ls -A "$PGDATA"`
if test "x$CONTENTS" = x
> Are we talking 7.0.1 material, btw?
Well, we would be if we were sure of the patch. I'm a little worried
about portability though. Given that this isn't a very critical issue
(IMHO) I'd recommend saving it for the 7.1 cycle.
regards, tom lane