Bug 972425

There's no way that the initdb script can fully recover from somebody doing "rm -rf /var/lib/pgsql".  At the very least, that will blow away the postgres user's .bash_profile; and he may very well have had other files in there too, since it's his home directory.  I don't think we'd be doing anybody a service by making it look like that is supposed to be a supported way to remove the data directory.

IMO, if you delete files that were installed by a package, you should expect to have to reinstall the package to recover from that.

Thanks tom, the inidb can recover, it does... as the postgresql-setup actually creates that directory, initdb does not mind .bash_profile or any other variable within $HOME of postgres.

If you think it should not recover, I suggest to replace the mkdir -p in this script with test of $(dirname $PGDATA) existence and die early.

Thanks!

IMO, this really does not make much sense to fix.  We could hack around to
infinity trying to catch users mistakes this or similar way.  But why not to
push to rawhide cleanup fix, as I see the two things are not necessary in the
script: (a) check for symlink non-existence and (b) the -p parameter for mkdir
(as the script unconditionally fails when /var/lib/pgsql does not exist).

I think only Rawhide is usable target for this.  Tom, I can close this if it
does not make sense to you even that way.

diff --git a/postgresql-setup b/postgresql-setup
index e566106..a755e11 100644
--- a/postgresql-setup
+++ b/postgresql-setup
@@ -66,9 +66,9 @@ script_result=0
 
 # code shared between initdb and upgrade actions
 perform_initdb(){
-       if [ ! -e "$PGDATA" -a ! -h "$PGDATA" ]
+       if [ ! -e "$PGDATA" ]
        then
-               mkdir -p "$PGDATA" || return 1
+               mkdir "$PGDATA" || return 1
                chown postgres:postgres "$PGDATA"
                chmod go-rwx "$PGDATA"
        fi

I agree the -p option is kind of pointless in light of this discussion.

I'm less sure about removing the -h test ... what exactly does -e do if the target is a dangling symlink?  Or mkdir for that matter?  I think the idea there was that if you want to put the data directory on some other partition, it should be sufficient to make a symlink leading to the desired place at /var/lib/pgsql/data and then do initdb.  Obviously the code will work if you also make a directory at the pointed-to spot, but what if you try to leave that step to the script?

OTOH, this may largely be moot now that the script doesn't run as root.  It's not clear that there are useful setups in which the parent directory of a relocated data directory would be owned by postgres; and if it isn't, you'd have to make the data directory by hand, as root, anyway.

(In reply to Tom Lane from comment #4)
> I agree the -p option is kind of pointless in light of this discussion.

Thanks, I'll commit that change.

> I'm less sure about removing the -h test ... what exactly does -e do if the
> target is a dangling symlink?  Or mkdir for that matter?
>
> I think the idea there was that if you want to put the data directory on some
> other partition, it should be sufficient to make a symlink leading to the
> desired place at /var/lib/pgsql/data and then do initdb.  Obviously the code
> will work if you also make a directory at the pointed-to spot, but what if
> you try to leave that step to the script?

For that functionality, we would have to incorporate readlink and try to create
the targed of the symlink, probably.

> OTOH, this may largely be moot now that the script doesn't run as root.
> It's not clear that there are useful setups in which the parent directory of
> a relocated data directory would be owned by postgres; and if it isn't, you'd
> have to make the data directory by hand, as root, anyway.

I thought about dangling symlink case.  But as it was not handled in
postgresql-setup (checked by quick testing), /usr/bin/initdb failed to win.

This check removal would make very unlikely fail to come little bit earlier in
code path - and I think that as users are familiar with initdb requirements,
they will not rely on automatic directory creation on a pointed-to place.

Thus I'll probably go for -h check removal — if nobody beats me :) — also.

postgresql-9.2.4-2.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/postgresql-9.2.4-2.fc18

postgresql-9.2.4-7.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/postgresql-9.2.4-7.fc19

Package postgresql-9.2.4-2.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing postgresql-9.2.4-2.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-14828/postgresql-9.2.4-2.fc18
then log in and leave karma (feedback).

postgresql-9.2.4-7.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

postgresql-9.2.5-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/postgresql-9.2.5-1.fc18

Package postgresql-9.2.5-1.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing postgresql-9.2.5-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-19316/postgresql-9.2.5-1.fc18
then log in and leave karma (feedback).

postgresql-9.2.5-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.