[ redirecting to -hackers ] <jeffrey.marsh...@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 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers