MIME-Version: 1.0
In-Reply-To: 
 <CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com>
References: 
 <CAHGQGwE48ViDkwybpxjXuf-trC87Ar1jdCHZ+ogtduoo3uvB8w@mail.gmail.com>
 <20150715085751.GD2301@postgresql.org>
 <CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com>
Date: Mon, 3 Aug 2015 20:56:27 -0400
Message-ID: 
 <CA+TgmoZMbtM94LxedPFp9oHecRGkq-ReunYBnu+F_VkBW9m2OA@mail.gmail.com>
Subject: Re: max_worker_processes on the standby
From: Robert Haas <robertmhaas@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
 pgsql-docs <pgsql-docs@postgresql.org>
Content-Type: text/plain; charset=UTF-8
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

On Thu, Jul 16, 2015 at 12:07 AM, Fujii Masao <masao.fujii@gmail.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


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