Re: Stronger safeguard for archive recovery not to miss data

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "osumi(dot)takamichi(at)fujitsu(dot)com" <osumi(dot)takamichi(at)fujitsu(dot)com>, 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Stronger safeguard for archive recovery not to miss data
Date: 2021-01-20 04:10:28
Message-ID: 23b6dd09-d837-7f6c-e601-5b150b75d6ac@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2021/01/20 1:05, Laurenz Albe wrote:
> On Mon, 2021-01-18 at 07:34 +0000, osumi(dot)takamichi(at)fujitsu(dot)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 primary server"),
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-01-20 04:35:06 Re: Some coverage for DROP OWNED BY with pg_default_acl
Previous Message Amit Kapila 2021-01-20 03:54:35 Re: Deleting older versions in unique indexes to avoid page splits