MIME-Version: 1.0
In-Reply-To: <20150715085751.GD2301@postgresql.org>
References: 
 <CAHGQGwE48ViDkwybpxjXuf-trC87Ar1jdCHZ+ogtduoo3uvB8w@mail.gmail.com>
 <20150715085751.GD2301@postgresql.org>
Date: Thu, 16 Jul 2015 13:07:50 +0900
Message-ID: 
 <CAHGQGwHereDzzzmfxEBYcVQu3oZv6vZcgu1TPeERWbDc+gQ06g@mail.gmail.com>
Subject: Re: max_worker_processes on the standby
From: Fujii Masao <masao.fujii@gmail.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: pgsql-docs <pgsql-docs@postgresql.org>
Content-Type: multipart/mixed; boundary=089e01538cbefa67a2051af636af
Precedence: bulk
Sender: pgsql-docs-owner@postgresql.org

--089e01538cbefa67a2051af636af
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 15, 2015 at 5:57 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Fujii Masao wrote:
>> Hi,
>>
>> "25.5.3. Administrator's Overview" in the document
>> -----------------------------------------------------
>> The setting of some parameters on the standby will need reconfiguration
>> if they have been changed on the primary. For these parameters,
>> the value on the standby must be equal to or greater than the value
>> on the primary. If these parameters are not set high enough then
>> the standby will refuse to start. Higher values can then be supplied
>> and the server restarted to begin recovery again. These parameters are:
>>     max_connections
>>     max_prepared_transactions
>>     max_locks_per_transaction
>> -----------------------------------------------------
>>
>> I found that the value of max_worker_processes on the standby also
>> must be equal to or greater than the value on the master. So we should
>> just add max_worker_processes to this paragraph. Patch attached.
>
> True.  Also track_commit_timestamp.

Yes, but I intentionally did not include track_commit_timestamp in
the patch because it's not easy for me to document the hot standby
condition of track_commit_timestamp unless I read the code more.

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.

> Can you add a comment somewhere in
> CheckRequiredParameterValues(void) that the set of parameters is listed
> in section such-and-such in the docs, so that next time there's a higher
> chance that the docs are kept up to date?

+1

What about the attached patch?

Regards,

-- 
Fujii Masao

--089e01538cbefa67a2051af636af
Content-Type: text/x-patch; charset=US-ASCII; name="doc_v2.patch"
Content-Disposition: attachment; filename="doc_v2.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ic5oeleu0

KioqIGEvZG9jL3NyYy9zZ21sL2hpZ2gtYXZhaWxhYmlsaXR5LnNnbWwKLS0t
IGIvZG9jL3NyYy9zZ21sL2hpZ2gtYXZhaWxhYmlsaXR5LnNnbWwKKioqKioq
KioqKioqKioqCioqKiAyMDM1LDIwNDAgKioqKiBMT0c6ICBkYXRhYmFzZSBz
eXN0ZW0gaXMgcmVhZHkgdG8gYWNjZXB0IHJlYWQgb25seSBjb25uZWN0aW9u
cwotLS0gMjAzNSwyMDQ1IC0tLS0KICAgICAgICAgICA8dmFybmFtZT5tYXhf
bG9ja3NfcGVyX3RyYW5zYWN0aW9uPC8+CiAgICAgICAgICA8L3BhcmE+CiAg
ICAgICAgIDwvbGlzdGl0ZW0+CisgICAgICAgIDxsaXN0aXRlbT4KKyAgICAg
ICAgIDxwYXJhPgorICAgICAgICAgIDx2YXJuYW1lPm1heF93b3JrZXJfcHJv
Y2Vzc2VzPC8+CisgICAgICAgICA8L3BhcmE+CisgICAgICAgIDwvbGlzdGl0
ZW0+CiAgICAgICAgPC9pdGVtaXplZGxpc3Q+CiAgICAgPC9wYXJhPgogIAoq
KiogYS9zcmMvYmFja2VuZC9hY2Nlc3MvdHJhbnNhbS94bG9nLmMKLS0tIGIv
c3JjL2JhY2tlbmQvYWNjZXNzL3RyYW5zYW0veGxvZy5jCioqKioqKioqKioq
KioqKgoqKiogNTgxNyw1ODIyICoqKiogZG8geyBcCi0tLSA1ODE3LDU4MjYg
LS0tLQogIC8qCiAgICogQ2hlY2sgdG8gc2VlIGlmIHJlcXVpcmVkIHBhcmFt
ZXRlcnMgYXJlIHNldCBoaWdoIGVub3VnaCBvbiB0aGlzIHNlcnZlcgogICAq
IGZvciB2YXJpb3VzIGFzcGVjdHMgb2YgcmVjb3Zlcnkgb3BlcmF0aW9uLgor
ICAqCisgICogTm90ZSB0aGF0IGFsbCB0aGUgcGFyYW1ldGVycyB3aGljaCB0
aGlzIGZ1bmN0aW9uIHRlc3RzIG5lZWQgdG8gYmUKKyAgKiBsaXN0ZWQgaW4g
QWRtaW5pc3RyYXRvcidzIE92ZXJ2aWV3IHNlY3Rpb24gaW4gaGlnaC1hdmFp
bGFiaWxpdHkuc2dtbC4KKyAgKiBJZiB5b3UgY2hhbmdlIHRoZW0sIGRvbid0
IGZvcmdldCB0byB1cGRhdGUgdGhlIGxpc3QuCiAgICovCiAgc3RhdGljIHZv
aWQKICBDaGVja1JlcXVpcmVkUGFyYW1ldGVyVmFsdWVzKHZvaWQpCg==

--089e01538cbefa67a2051af636af
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


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

--089e01538cbefa67a2051af636af--