[ redirecting to -hackers ]
<[email protected]> 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 protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
