pgsql: Make crash recovery ignore recovery target settings.
Make crash recovery ignore recovery target settings.
In v11 or before, recovery target settings could not take effect in
crash recovery because they are specified in recovery.conf and
crash recovery always starts without recovery.conf. But commit
2dedf4d9a8 integrated recovery.conf into postgresql.conf and
which unexpectedly allowed recovery target settings to take effect
even in crash recovery. This is definitely not good behavior.
To fix the issue, this commit makes crash recovery always ignore
recovery target settings.
Back-patch to v12.
Author: Peter Eisentraut
Reviewed-by: Fujii Masao
Discussion: /messages/by-id/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net
Branch
------
REL_12_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/4af2ac3deeca24d3b8cb1abeb49bd62a7d013fa3
Modified Files
--------------
src/backend/access/transam/xlog.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Hi Fujii-san,
On Mon, Sep 30, 2019 at 01:21:00AM +0000, Fujii Masao wrote:
Make crash recovery ignore recovery target settings.
In v11 or before, recovery target settings could not take effect in
crash recovery because they are specified in recovery.conf and
crash recovery always starts without recovery.conf. But commit
2dedf4d9a8 integrated recovery.conf into postgresql.conf and
which unexpectedly allowed recovery target settings to take effect
even in crash recovery. This is definitely not good behavior.To fix the issue, this commit makes crash recovery always ignore
recovery target settings.Back-patch to v12.
It would be nice to avoid committing stuff into REL_12_STABLE until
the version is tagged (not stamped!) as the tarball wrap for the GA of
this week is going to be soon.
--
Michael
On Mon, Sep 30, 2019 at 11:45 AM Michael Paquier <michael@paquier.xyz> wrote:
Hi Fujii-san,
On Mon, Sep 30, 2019 at 01:21:00AM +0000, Fujii Masao wrote:
Make crash recovery ignore recovery target settings.
In v11 or before, recovery target settings could not take effect in
crash recovery because they are specified in recovery.conf and
crash recovery always starts without recovery.conf. But commit
2dedf4d9a8 integrated recovery.conf into postgresql.conf and
which unexpectedly allowed recovery target settings to take effect
even in crash recovery. This is definitely not good behavior.To fix the issue, this commit makes crash recovery always ignore
recovery target settings.Back-patch to v12.
It would be nice to avoid committing stuff into REL_12_STABLE until
the version is tagged (not stamped!) as the tarball wrap for the GA of
this week is going to be soon.
I was thinking this is open item for v12 and needs to be fixed before GA.
But per discussion in pgsql-release, the consensus seems to be to
ship GA first and fix that after GA. Sorry for my inattention...
I suspend to commit other recovery-related things until GA is tagged.
Regards,
--
Fujii Masao
On 9/29/19 11:02 PM, Fujii Masao wrote:
On Mon, Sep 30, 2019 at 11:45 AM Michael Paquier <michael@paquier.xyz> wrote:
Hi Fujii-san,
On Mon, Sep 30, 2019 at 01:21:00AM +0000, Fujii Masao wrote:
Make crash recovery ignore recovery target settings.
In v11 or before, recovery target settings could not take effect in
crash recovery because they are specified in recovery.conf and
crash recovery always starts without recovery.conf. But commit
2dedf4d9a8 integrated recovery.conf into postgresql.conf and
which unexpectedly allowed recovery target settings to take effect
even in crash recovery. This is definitely not good behavior.To fix the issue, this commit makes crash recovery always ignore
recovery target settings.Back-patch to v12.
It would be nice to avoid committing stuff into REL_12_STABLE until
the version is tagged (not stamped!) as the tarball wrap for the GA of
this week is going to be soon.I was thinking this is open item for v12 and needs to be fixed before GA.
But per discussion in pgsql-release, the consensus seems to be to
ship GA first and fix that after GA. Sorry for my inattention...
I suspend to commit other recovery-related things until GA is tagged.
I'm surprised that we would consider going to GA with an issue like this
outstanding.
--
-David
david@pgmasters.net
On Mon, Sep 30, 2019 at 7:28 AM David Steele <david@pgmasters.net> wrote:
I'm surprised that we would consider going to GA with an issue like this
outstanding.
Yeah, this is a *bad* problem.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Greetings,
* Robert Haas (robertmhaas@gmail.com) wrote:
On Mon, Sep 30, 2019 at 7:28 AM David Steele <david@pgmasters.net> wrote:
I'm surprised that we would consider going to GA with an issue like this
outstanding.Yeah, this is a *bad* problem.
I have to agree with this and I'm also pretty disappointed that we seem
to be 'damn the torpedos, full steam ahead' with these issues. I don't
like the idea of a delay either but ...
Thanks,
Stephen