From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeffrey(dot)Marshall(at)usitc(dot)gov, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file |
Date: | 2016-05-30 03:51:17 |
Message-ID: | CAB7nPqQ7j-sETLCGLiDXZifEpmHiLhwdgZO+7SnAE6uGAOMsag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Sat, May 28, 2016 at 9:57 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2016-05-27 20:54:43 -0400, Tom Lane wrote:
>> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Sridhar N Bamandlapally | 2016-05-30 07:25:19 | UUID datatype |
Previous Message | Julien Rouhaud | 2016-05-30 00:43:16 | Re: plugin dev, oid to pointer map |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Dunstan | 2016-05-30 04:37:56 | IPv6 link-local addresses and init data type |
Previous Message | Tsunakawa, Takayuki | 2016-05-30 03:04:24 | Question and suggestion about application binary compatibility policy |