Brian Pitts <b...@uga.edu> writes: > When an ext2, ext3, or ext4 filesystem is mounted directly on the PGDATA > directory, initdb will refuse to run because it sees 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers