>Mmm. Maybe something's missing. If you took the base-backup using >pg_basebackup, that means max_wal_senders > 0 on the primary. If you >lowered wal_level in the backup (or replica) then started it, You >would get something like this. >| FATAL: WAL streaming (max_wal_senders > 0) requires wal_level "replica" or >"logical". >If you changed max_wal_senders to zero, you would get the following instead. >| FATAL: hot standby is not possible because max_wal_senders = 0 is a lower >setting than on the primary server (its value was 2) Then mark hot_standby off and continue try lowered wal_level. And do recovery from the basebackup, then you will see the FATAL.
>So I couldn't reproduce the situation. >Anyways. >> My question is that what's the mean of [set wal_level to "replica" on the >> primary] in >> HINT describe, I can't think over a case to solve this FATAL by set >> wal_level, I can >> solve it by turn off hot_standby only. >> >> Do you think we can do this code change? >> --- a/src/backend/access/transam/xlog.c >> +++ b/src/backend/access/transam/xlog.c >> @@ -6300,7 +6300,7 @@ CheckRequiredParameterValues(void) >> 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."))); >> + errhint("You should turn off hot_standby here."))); >Since it's obvious that the change in a primary cannot be propagted by >taking a backup or starting replication, the first sentence reads to >me as "you should retake a base-backup from a primary where wal_level >is replica or higher". So *I* don't think it needs a fix. I think this HINT is want to guide users to finish this recovery, and the first guide is invalid in my opinion. Regards, Highgo Software (Canada/China/Pakistan) URL : www.highgo.ca EMAIL: mailto:movead(dot)li(at)highgo(dot)ca