[ redirecting to -hackers ]
<Jeffrey.Marshall@usitc.gov> writes:
> When performing a vanilla database restore using either the 9.2.16 or 9.2.17 executables (i.e. just restoring the
databasefiles 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
erroroccurred restoring both backups that were made under the current version (9.2.16 and 9.2.17) as well as backups
madeunder prior versions (9.2.15 at least). The exact same restore process/backup files can be used to successfully
restorethe database using the 9.2.15 executables, but fail when using either 9.2.16 or 9.2.17 with the permission
deniederror.
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