The behavior of CheckRequiredParameterValues()

On Wed, Mar 5, 2014 at 4:09 AM, Sawada Masahiko <sawada.mshk@gmail.com>wrote:

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.

The snapshot of running transaction information is written to WAL only when
the wal_level is set to 'hot_standby'.
This information is required on the standby side to recreate the running
transactions.

Regards,
Hari Babu
Fujitsu Australia

On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:

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 think checking it from the control file on a standby in recovery
means that we should confirm if the *wal_level with which the WAL was
generated* is sufficient to now become a hot standby after recovery
finishes.

--
Amit

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote <amitlangote09@gmail.com> wrote:

On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:

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 think checking it from the control file on a standby in recovery
means that we should confirm if the *wal_level with which the WAL was
generated* is sufficient to now become a hot standby after recovery
finishes.

Sorry, should have said:
*become a hot standby after recovery reaches a consistent state

--
Amit

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Mar 5, 2014 at 5:13 PM, Amit Langote <amitlangote09@gmail.com> wrote:

On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote <amitlangote09@gmail.com> wrote:

On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko <sawada.mshk@gmail.com> wrote:

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 think checking it from the control file on a standby in recovery
means that we should confirm if the *wal_level with which the WAL was
generated* is sufficient to now become a hot standby after recovery
finishes.

Sorry, should have said:
*become a hot standby after recovery reaches a consistent state

Thank you for explain!
I understood it!

Regards,

-------
Sawada Masahiko

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers