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 по дате отправления: