Re: Stronger safeguard for archive recovery not to miss data
От | Fujii Masao |
---|---|
Тема | Re: Stronger safeguard for archive recovery not to miss data |
Дата | |
Msg-id | 23b6dd09-d837-7f6c-e601-5b150b75d6ac@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Stronger safeguard for archive recovery not to miss data (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Stronger safeguard for archive recovery not to miss data
|
Список | 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 по дате отправления: