From: | Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | The behavior of CheckRequiredParameterValues() |
Date: | 2014-03-04 17:09:44 |
Message-ID: | CAD21AoBeMoY6ajXkM4Oqhv5wVOgu17a9bdhHBq9Sh_SFZorXzA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
I had doubts regarding behavior of CheckRequiredParameterValues() function.
I could not start standby server which is created by pg_basebackup
with following scenario.
1. Start the master server with 'wal_level = archve' , 'hot_standby =
on' and other settings of replication.
2. Create the standby server from the master server by using pg_basebackup.
3. Change the wal_level value of both master and standby server to
'hot_standby'.
4. Restarting the master server.
5. Starting the standby server.
In #5, I got following error even if I set wal_level to 'hot_standby'.
FATAL: hot standby is not possible because wal_level was not set to
"hot_standby" or higher on the master server
I tried to investigate this behaviour.
Currently CheckRequiredParameterValues() function uses wal_level value
which is got from ControlFile when comparing between wal_level and
WAL_LEVEL_HOT_STANDBY as following code.
xlog.c:6177
if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
ereport(ERROR,
(errmsg("hot standby is not possible because wal_level was not
So we have to start and stop standby server with changed
wal_level(i.g., hot_standby) if we want to enable hot standby.
In this case, I think that the standby server didn't need to confirm
wal_level value of ControlFile.
I think that it should confirm value which is written in postgreql.conf.
I might be missing something.
Please let me know that.
Regards,
-------
Sawada Masahiko
From | Date | Subject | |
---|---|---|---|
Next Message | Atri Sharma | 2014-03-04 17:21:14 | Re: ALTER TABLE lock strength reduction patch is unsafe |
Previous Message | Stephen Frost | 2014-03-04 16:50:22 | Re: ALTER TABLE lock strength reduction patch is unsafe |