From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | jmm(at)cvni(dot)net, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Bug #844: initdb fails on an ext2/3 fs mounted on /var/lib/pgsql/data |
Date: | 2002-12-11 05:46:30 |
Message-ID: | 9324.1039585590@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
pgsql-bugs(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2002-12-11 11:25:31 | Bug #845: JDBC driver have a problem with floating-point numbers |
Previous Message | Tom Lane | 2002-12-11 04:37:18 | Re: [HACKERS] GEQO Triggers Server Crash |