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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers