On Sat, May 28, 2016 at 9:57 AM, Andres Freund <and...@anarazel.de> wrote: > On 2016-05-27 20:54:43 -0400, Tom Lane wrote: >> Andres Freund <and...@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. Even with the current code, the first file that needs to be writable is the first WAL segment of the new timeline, which is made as a copy of the last partial segment of the old timeline. Anyway, I agree with Andres here. We had definitely better be sure that durable_rename does fsync correctly the old and new entries when doing a rename meaning that failing on EPERM is adapted, or we may lose the rename in case of a crash, and data would be lost if the rename was not seen as effective. And personally I am more worrying about data losses than strangely designed restore_command scripts, which is likely using sudo. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
