>> Currently src/port/pgcheckdir.c will reject non-empty
>> directories, which is an issue during initdb(1) when PGDATA is
>> also the mount point for filesystems that support snapshots (e.g.
>> ZFS or UFS2).
>
>> Granted it's not hard to create a subdirectory, initdb there and
>> move the contents of the files around, it's extra work that
>> shouldn't be required.
>
> I feel that it is very bad practice to use the mount point as the
> PGDATA directory. It forcloses a lot of reasonable actions that
> someone managing the database server might want to take.
The only reason I have skin in this game is because pg_check_dir(xlog_dir) is called and I routinely have to work
aroundthat nuisance/nugget of joy. Again, just a nuisance.
It's common to create a ZFS dataset for specific applications (`zfs send ... | ssh zfs receive ...`). In SAN
environments,mounting a LUN as PGDATA or pg_xlog isn't uncommon either.
I agree it's not ideal for some filesystems, but being overly protective doesn't buy us much either, because in some
setups,it's entirely acceptable. If PostgreSQL had the ability to chroot(2) itself, I'd be very opposed to this patch,
butas is, it's mostly harmless (the rev that didn't have lost+found, actually).
In thinking about it, I like ignoring the hidden directories and failing when lost+found is present because, IMO,
filesystemswhere lost+found is going to be present are exactly the filesystems that shouldn't have PGDATA located at
thetop of a mount point.
Personally I'm a fan of having PGDATA's parent directory be its own dataset/filesystem as well, but that's because I
wantPGDATA's parent directory to include PostgreSQL's minor version number (e.g. zpool datasets: tank/pg tank/pg/data
tank/pg/data/9.2),but I digress.
> It's hard to get enthusiastic about a patch to make bad practice
> more convenient. I would rather add a sentence or two to the
> initdb documentation recommending that a cluster not be created at
> a mount point; it should be created in a directory underneath the
> mount point.
Giving filesystem advice is a large topic that I'm sure is covered someplace in the handbook. A general warning isn't a
badidea, however. *shrug*
Regardless, hopefully some of this is of interest to someone.
-sc
--
Sean Chittenden
sean@chittenden.org
