On 2016-05-30 12:51:17 +0900, Michael Paquier wrote:
> On Sat, May 28, 2016 at 9:57 AM, Andres Freund <andres@anarazel.de> wrote:
> > On 2016-05-27 20:54:43 -0400, Tom Lane wrote:
> >> Andres Freund <andres@anarazel.de> writes:
> >> > 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.
> >>
> >> s/not readable/not writable/. I doubt that it's a good idea for that
> >> code to think that it can fail hard on non-writable files.
> >
> > But we actually sometimes write to files we've recovered; if they're the
> > end of the WAL after archive recovery and/or promotion. If a
> > restore_command restores files in a non-writable way it's buggy; I don't
> > see why it's worthwhile to work around that.
>
> Not exactly, startup process does not write directly to the files of
> pg_xlog while in recovery.
It does at the end of crash recovery. And the wal receiver does so at
the end of archive recovery (which can repeatedly be reached).
- Andres