Re: Stronger safeguard for archive recovery not to miss data - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Stronger safeguard for archive recovery not to miss data
Date
Msg-id 23b6dd09-d837-7f6c-e601-5b150b75d6ac@oss.nttdata.com
Whole thread Raw
In response to Re: Stronger safeguard for archive recovery not to miss data  (Laurenz Albe <laurenz.albe@cybertec.at>)
Responses Re: Stronger safeguard for archive recovery not to miss data  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers

On 2021/01/20 1:05, Laurenz Albe wrote:
> On Mon, 2021-01-18 at 07:34 +0000, osumi.takamichi@fujitsu.com wrote:
>> I noticed that this message should cover both archive recovery modes,
>> which means in recovery mode and standby mode. Then, I combined your
>> suggestion above with this point of view. Have a look at the updated patch.
>> I also enriched the new tap tests to show this perspective.
> 
> Looks good, thanks.
> 
> I'll mark this patch as "ready for committer".

+                 errhint("Run recovery again from a new base backup taken after setting wal_level higher than
minimal")));

Isn't it impossible to do this in normal archive recovery case? In that case,
since the server crashed and the database got corrupted, probably
we cannot take a new base backup.

Originally even when users accidentally set wal_level to minimal, they could
start the server from the backup by disabling hot_standby and salvage the data.
But with the patch, we lost the way to do that. Right? I was wondering that
WARNING was used intentionally there for that case.


        if (ControlFile->wal_level < WAL_LEVEL_REPLICA)
            ereport(ERROR,
                    (errmsg("hot standby is not possible because wal_level was not set to \"replica\" or higher on the
primaryserver"),
 
                     errhint("Either set wal_level to \"replica\" on the primary, or turn off hot_standby here.")));

With the patch, we never reach the above code?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Deleting older versions in unique indexes to avoid page splits
Next
From: Michael Paquier
Date:
Subject: Re: Some coverage for DROP OWNED BY with pg_default_acl