From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-docs <pgsql-docs(at)postgresql(dot)org> |
Subject: | Re: max_worker_processes on the standby |
Date: | 2015-08-04 00:56:27 |
Message-ID: | CA+TgmoZMbtM94LxedPFp9oHecRGkq-ReunYBnu+F_VkBW9m2OA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On Thu, Jul 16, 2015 at 12:07 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> One example which makes me a bit confusing is; both master and
> standby are running fine with track_commit_timestamp disabled,
> then I enable it only on the master. That is, the value of
> track_commit_timestamp is not the same between master and standby.
> No error happens in this case. According to the code of xlog_redo(),
> the commit timestamp tracking mechanism is activated in this case.
> However, after that, if standby is restarted, standby emits an error
> because the value of track_commit_timestamp is not the same between
> master and standby. Simple question is; why do we need to cause
> the standby fail in this case? Since I'm not familiar with the code of
> track_commit_timestamp yet, I'm not sure whether this behavior is
> valid or not.
Hmm, that seems like awfully weird behavior.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-08-04 04:41:26 | Re: max_worker_processes on the standby |
Previous Message | Alvaro Herrera | 2015-08-03 18:37:29 | Re: Confused by example in 13.2.2 |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-08-04 01:14:00 | Re: Doubt about AccessExclusiveLock in ALTER TABLE .. SET ( .. ); |
Previous Message | Amit Langote | 2015-08-04 00:19:17 | Re: Transactions involving multiple postgres foreign servers |