Re: [HACKERS] max_worker_processes on the standby

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] max_worker_processes on the standby
Дата
Msg-id CA+TgmoasssOk0n1whCqZAzewkt88_y_mk5E5JMR-qGa_b6dXSQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] max_worker_processes on the standby  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-docs
On Thu, Oct 29, 2015 at 5:41 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> I found another strange behavior on track_commit_timestamp.
> Here are the steps to reproduce it.
>
> 1. Start the master and standby servers with track_commit_timestamp enabled.
>     Since committs is activated in standby, pg_last_committed_xact() can
>     successfully return the timestamp of last transaction as expected.
>
> 2. Disable track_commit_timestamp in the master and restart the master server.
>     The parameter-change WAL record is streamed to the standby and committs
>     is deactivated. pg_last_committed_xact() causes an ERROR in the standby.
>
> 3. Run checkpoint in the master.
>
> 4. Run restartpoint in the standby after the checkpoint WAL record generated
>     in #3 is replicated to the standby.
>
> 5. Restart the standby server.
>     Committs is activated in the standby because track_commit_timestamp is
>     enabled.

This seems wrong already at this point.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


В списке pgsql-docs по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: [HACKERS] max_worker_processes on the standby
Следующее
От: Alexander Lakhin
Дата:
Сообщение: Re: Moving documentation to XML