Re: BUG #15331: Please check if recovery.conf can be renamed

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: spam_from_pgsql_lists(at)chezphil(dot)org, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15331: Please check if recovery.conf can be renamed
Date: 2018-08-18 08:15:30
Message-ID: 20180818081530.GB2574@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, Aug 16, 2018 at 05:09:43AM -0700, Andres Freund wrote:
> How would this address OP's concern? You'd still not learn meaningfully
> earlier that your attempted promotion failed (instead of learning of the
> problem before you ever promote).

The problem that the previous commit fixes is to make sure that even if
recovery.conf renaming fails, then the cluster does not get into a weird
state, making it reusable later on, and the OP would not see the later
problems reported after the failed promotion. I am not sure that using
a warning at an early stage would be actually useful as I doubt that any
user would remark it, but there could be indeed an argument to make sure
that recovery.conf has a correct permission set, and fail hard before
entering recovery if that's not the case. I am not sure how much we
want to restrict things though, lately has been for example introduced
read grouping access in data folders...
--
Michael

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Jeff Janes 2018-08-18 14:23:34 Re: BUG #15335: Documentation is wrong about archive_command and existing files
Previous Message Tom Lane 2018-08-17 20:12:09 Re: BUG #15338: pg_restore --disable-triggers --data-only AND schema for table is not set.