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
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. |