Re: [HACKERS] The behavior of CheckRequiredParameterValues()
On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote amitlangot...@gmail.com wrote: On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko sawada.m...@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
Re: [HACKERS] The behavior of CheckRequiredParameterValues()
On Wed, Mar 5, 2014 at 5:13 PM, Amit Langote amitlangot...@gmail.com wrote: On Wed, Mar 5, 2014 at 12:07 PM, Amit Langote amitlangot...@gmail.com wrote: On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko sawada.m...@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
[HACKERS] The behavior of CheckRequiredParameterValues()
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] The behavior of CheckRequiredParameterValues()
On Wed, Mar 5, 2014 at 4:09 AM, Sawada Masahiko sawada.m...@gmail.comwrote: 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
Re: [HACKERS] The behavior of CheckRequiredParameterValues()
On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko sawada.m...@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
