Strange issue with initdb on 8.0 and Solaris automounts

Folks,

I ran into an interesting issue when installing PostgreSQL 8.0 that I'm
not sure how to resolve correctly. My system is a Sun machine (Blade
1000) running Solaris 9, with relatively recent patches. After install-
ing 8.0, I went to run the 'initdb' command and was greeted with the
following:

[delirium:postgres] ~
(11) initdb -D /software/postgresql-8.0.0/data
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /software/postgresql-8.0.0/data ... initdb: could not create directory "/software/postgresql-8.0.0": Operation not applicable

The error message was a bit confusing, so I decided to run a truss on
the process to see what might be happening, and this is what I came
across:

[...]
8802/1: write(1, " c r e a t i n g d i r".., 62) = 62
8802/1: umask(0) = 077
8802/1: umask(077) = 0
8802/1: mkdir("/software", 0777) Err#17 EEXIST
8802/1: stat64("/software", 0xFFBFC858) = 0
8802/1: mkdir("/software/postgresql-8.0.0", 0777) Err#89 ENOSYS
[...]

The last error in that section, ENOSYS, is very strange, as the Solaris
manpage for 'mkdir' does not mention it as a possible error. One thing
to note in this, however, is that '/software/postgresql-8.0.0' is not a
regular directory, but an automount point (which in this case is just a
local loopback mount). So the indication is that Solaris seems to have
a bug not in mkdir, but deeper in their VFS code that's causing this
seemingly strange issue.

Two workarounds for this problem have been found: running 'initdb' with
a directory that's *not* an automount point and then moving the 'data'
directory to its final destination worked fine, along with a suggestion
from Andrew Dunstan (on the #postgresql IRC channel) with using a rela-
tive path for the data directory. Both were successful in avoiding the
issue, but I decided to mention this here in case someone felt it might
be worth looking into to see if the Sun problem can be avoided; I am
going to notify Sun of their bug, just don't know how long it will take
them to actually resolve it (if they ever do).

While I can fully understand that a code change here may not be desire-
able, might some notes in the documentation be useful for those who
might stumble across the problem as well? Just a suggestion...

I hope I gave sufficient information on the problem, though I'm always
willing to give any clarification needed. Thank you for your time.

Ken Lareau
elessar(at)numenor(dot)org