Re: [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file

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