Обсуждение: Bug #844: initdb fails on an ext2/3 fs mounted on /var/lib/pgsql/data

JMM (jmm@cvni.net) reports a bug with a severity of 4
The lower the number the more severe it is.

Short Description
initdb fails on an ext2/3 fs mounted on /var/lib/pgsql/data

Long Description
If a whole filesystem (eg a whole disk in one filesystem that is dedicated to postgres data) is mounted on data
location(typically /var/lib/pgsql/data), initdb files besause of the existence of the lost+found directory in the
filesystemroot. 

There is an easy by pass by moving lost+found elsewhere, run initdb and re move lost+found to its original location.
Nevertheless,having initdb tolerate lost+found (or equivalents for other fs types) would be an  improvement. 

Sample Code


No file was uploaded with this report

pgsql-bugs@postgresql.org writes:
> If a whole filesystem (eg a whole disk in one filesystem that is
> dedicated to postgres data) is mounted on data location (typically
> /var/lib/pgsql/data), initdb files besause of the existence of the
> lost+found directory in the filesystem root.

> There is an easy by pass by moving lost+found elsewhere, run initdb
> and re move lost+found to its original location. Nevertheless, having
> initdb tolerate lost+found (or equivalents for other fs types) would
> be an improvement.

Hmm.  Plan B would be to create a data directory just under the mount
point and let PGDATA point there, rather than at the actual filesystem
root directory.  I am inclined to think that Plan B is considerably
safer than what you propose, because what you propose requires that the
unprivileged postgres user own the filesystem root directory.  That
seems like a bad idea (should postgres be able to remove/rename
lost+found?  No sir.)

Certainly it would be easy to make initdb ignore "lost+found" appearing
in the target directory ... I'm just not seeing the argument why this
setup is really a good idea.

            regards, tom lane