David Noel <david.i.noel@xxxxxxxxx> writes: > On 12/14/12, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: >> This corresponds to the execution of XLogFileInit(), and what's >> evidently happening is that we successfully create and zero-fill >> the first xlog segment file under a temporary name, but then >> the attempt to rename it into place with link() fails with EPERM. >> >> This is really a WTF kind of failure, I think. The directory is >> certainly writable --- it was made under our own UID, and what's >> more we just managed to create the file there under its temp name. >> So how can we get an EPERM failure from link()? >> >> I think this is a kernel bug. > Thanks so much for the analysis. Where to from here? The > freebsd-database@xxxxxxxxxxx mailing list? The postgresql port > maintainer? Who should I be in touch with? You need to talk to some FreeBSD kernel hackers about why link() might be failing here. Since you see it on UFS too, we can probably exonerate the ZFS filesystem-specific code. I did some googling and found that EPERM can be issued if the filesystem doesn't support hard links (which shouldn't apply to ZFS I trust). Also, Linux has a "protected_hardlinks" option that causes certain attempts at creating hard links to fail --- but our use-case here doesn't fall foul of any of those restrictions AFAICS, and of course FreeBSD isn't Linux. Still, I wonder if you're running into some misdesigned or misimplemented security restriction. You might want to look at your kernel parameters and see if any of them look like they might have to do with restricting hard-link operations. Also, since Amitabh failed to duplicate the failure on both earlier and later FreeBSD kernels, and we've not heard reports of this from anybody else either, it seems more than possible that it's a plain old bug in the specific kernel version you're using. As a short-term workaround, I'd suggest rebuilding with HAVE_WORKING_LINK disabled. (Just remove that #define from src/include/pg_config_manual.h and rebuild.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
