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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jeffrey(dot)Marshall(at)usitc(dot)gov, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [GENERAL] Permission Denied Error on pg_xlog/RECOVERYXLOG file
Date: 2016-06-03 18:12:13
Message-ID: 20160603181213.albwca5boutdiy5m@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On 2016-06-03 14:00:00 -0400, Robert Haas wrote:
> On Fri, May 27, 2016 at 8:44 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > 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.
>
> So if we made this a WARNING rather than an ERROR, it wouldn't hiding
> the issue, but it would be less likely to break things that worked
> before. No?

Except that we're then accepting the (proven!) potential for data
loss. We're talking about a single report of an restore_command setting
odd permissions. Which can easily be fixed. And the permission setting
already has downsides, e.g. for the switch between archive and streaming
recovery (which would fail).

Andres

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2016-06-03 19:03:39 Re: Change in order of criteria - reg
Previous Message Robert Haas 2016-06-03 18:04:01 Re: [HACKERS] Change in order of criteria - reg

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-06-03 18:20:04 Re: Perf Benchmarking and regression.
Previous Message Robert Haas 2016-06-03 18:04:01 Re: [HACKERS] Change in order of criteria - reg