Re: [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

[ redirecting to -hackers ]

<Jeffrey(dot)Marshall(at)usitc(dot)gov> writes:
> When performing a vanilla database restore using either the 9.2.16 or 9.2.17 executables (i.e. just restoring the database files from a 'tar' backup and reading the WAL files created during the 'tar' backup - no specific PIT given in recovery.conf) the database server will abort with a permission denied error on the pg_xlog/RECOVERYXLOG file. The error occurred restoring both backups that were made under the current version (9.2.16 and 9.2.17) as well as backups made under prior versions (9.2.15 at least). The exact same restore process/backup files can be used to successfully restore the database using the 9.2.15 executables, but fail when using either 9.2.16 or 9.2.17 with the permission denied error.

There were not very many changes between 9.2.15 and 9.2.16. Between that
and the location of the error:

> 2016-04-27 17:02:06 EDT 572128cd.1811 [7-1] user=,db=,remote= FATAL: 42501:
> could not open file "pg_xlog/RECOVERYXLOG": Permission denied
> 2016-04-27 17:02:06 EDT 572128cd.1811 [8-1] user=,db=,remote= LOCATION:
> fsync_fname_ext, fd.c:2654

I feel pretty confident in blaming this on the "durable_rename" patch.

The proximate cause of this might just be that the "ignore_perm" exception
is only for EACCES and not EPERM (why?). In general, though, it seems to
me that the durable_rename patch has introduced a whole lot of new failure
conditions that were not there before, for IMO very little reason.
I think we would be better off fixing those functions so that there is
*no* case other than failure of the rename() or link() call itself that
will be treated as a hard error. Blowing up completely is not an
improvement over not fsyncing.

regards, tom lane