Brian Pitts <bdp@uga.edu> writes:
> When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA directory, initdb will refuse to run because
itsees the
> lost+found directory that mke2fs created and assumes the PGDATA directory is already in use for something other than
PostgreSQL.
> Attached is a patch against master which will cause a directory that contains only lost+found to still be treated as
empty.
This has been proposed before, and rejected before, on the grounds that
you shouldn't be using a mount-point directory as a data directory
anyway. Better practice is to make a postgres-owned directory just
underneath the mount point. A couple of reasons for that are:
1. Mount-point directories should be owned by root, never by an
unprivileged account such as postgres. IIRC there are good security
reasons for this practice, though I don't recall all the details right
now.
2. Keeping the data directory one level down ensures a clean failure if
the disk is for some reason not mounted when Postgres starts, or goes
offline later. Otherwise, particularly if you're using a start script
that will automatically try an initdb, you might end up with some data
files on the / volume underneath where the mount point should have been.
This is sure to lead to serious problems when the disk does come back
online. There's at least one horror story in our archives from someone
who had an auto-initdb startup script and one day his NFS disk was a few
seconds slow to mount...
> This was previously proposed in 2001; see http://archives.postgresql.org/pgsql-hackers/2001-03/msg01194.php
It's been discussed more recently than that, I believe.
regards, tom lane