Re: max_worker_processes on the standby
On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Aug 4, 2015 at 6:13 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
I think it's totally reasonable for the standby to follow the master's
behavior rather than the config file. That should be documented, but
otherwise, no problem. If it were technologically possible for the
standby to follow the config file rather than the master in all cases,
that would be fine, too. But the current behavior is somewhere in the
middle, and that doesn't seem like a good plan.So I discussed this with Petr. He points out that if we make the
standby follows the master, then the problem would be the misbehavior
that results once the standby is promoted: at that point the standby
would no longer "follow the master" and would start with the feature
turned off, which could be disastrous (depending on what are you using
the commit timestamps for).That seems like an imaginary problem. If it's critical to have commit
timestamps, don't turn them off on the standby.To solve that problem, you could suggest that if we see the setting
turned on in pg_control then we should follow that instead of the config
file; but then the problem is that there's no way to turn the feature
off. And things are real crazy by then.There's no existing precedent for a feature that lets the standby be
different from the master *in any way*. So I don't see why we should
start here. I think the reasonable definition is that the GUC
controls whether the master tries to update the SLRU (and generate
appropriate WAL records, presumably). The standby should not get a
choice about whether to replay those WAL records.
+1
I added this to the 9.5 open item list.
Regards,
--
Fujii Masao
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
On 2015-09-03 15:03, Fujii Masao wrote:
On Sat, Aug 8, 2015 at 11:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
There's no existing precedent for a feature that lets the standby be
different from the master *in any way*. So I don't see why we should
start here. I think the reasonable definition is that the GUC
controls whether the master tries to update the SLRU (and generate
appropriate WAL records, presumably). The standby should not get a
choice about whether to replay those WAL records.+1
I added this to the 9.5 open item list.
I see I forgot to send patch for this, so here it is. It just removes
the on start check for track_commit_timestamp being same in config and
control file.
--
Petr Jelinek http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachments:
committs-standby-fix.patchapplication/x-patch; name=committs-standby-fix.patchDownload
From 49533f556d8120564ed81dc67acfcc03d2894166 Mon Sep 17 00:00:00 2001
From: Petr Jelinek <pjmodos@pjmodos.net>
Date: Wed, 16 Sep 2015 04:29:29 +0200
Subject: [PATCH] committs-standby-fix
---
src/backend/access/transam/xlog.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index a092aad..fc5a1d7 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -5826,19 +5826,6 @@ do { \
minValue))); \
} while(0)
-#define RecoveryRequiresBoolParameter(param_name, currValue, masterValue) \
-do { \
- bool _currValue = (currValue); \
- bool _masterValue = (masterValue); \
- if (_currValue != _masterValue) \
- ereport(ERROR, \
- (errcode(ERRCODE_INVALID_PARAMETER_VALUE), \
- errmsg("hot standby is not possible because it requires \"%s\" to be same on master and standby (master has \"%s\", standby has \"%s\")", \
- param_name, \
- _masterValue ? "true" : "false", \
- _currValue ? "true" : "false"))); \
-} while(0)
-
/*
* Check to see if required parameters are set high enough on this server
* for various aspects of recovery operation.
@@ -5885,9 +5872,6 @@ CheckRequiredParameterValues(void)
RecoveryRequiresIntParameter("max_locks_per_transaction",
max_locks_per_xact,
ControlFile->max_locks_per_xact);
- RecoveryRequiresBoolParameter("track_commit_timestamp",
- track_commit_timestamp,
- ControlFile->track_commit_timestamp);
}
}
--
1.9.1