[ 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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to