Re: Bug #844: initdb fails on an ext2/3 fs mounted on /var/lib/pgsql/data
От | Tom Lane |
---|---|
Тема | Re: Bug #844: initdb fails on an ext2/3 fs mounted on /var/lib/pgsql/data |
Дата | |
Msg-id | 9324.1039585590@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Bug #844: initdb fails on an ext2/3 fs mounted on /var/lib/pgsql/data (pgsql-bugs@postgresql.org) |
Список | pgsql-bugs |
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
В списке pgsql-bugs по дате отправления: