On 2016-05-26 12:44:51 -0400, Tom Lane wrote:
> > 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
So, what's the permission of RECOVERYXLOG at that point? It's pretty
weird that directly after running reason_command it's not readable. Are
you doing something involving sudo or such in restore_command?
> The proximate cause of this might just be that the "ignore_perm" exception
> is only for EACCES and not EPERM (why?).
I essentially just copied your logic from d8179b001ae574da00c8 ff.
> 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.
Uh. Like provably loosing data after crashes?
> 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.
I'm not convinced of that. Hiding unexpected issues for longer, just to
continue kind-of-operating, can make the impact of problems a lot worse,
and it makes it very hard to actually learn about the issues.
Andres