Subject: Re: [DOCS] max_worker_processes on the standby
To: Alvaro Herrera <alvherre@2ndquadrant.com>,
 Fujii Masao <masao.fujii@gmail.com>
References: 
 <CAHGQGwGmpuWUHUcMXFrexgYjAvzn7a8mNdZfXzFG8aBjoXyd4w@mail.gmail.com>
 <20151002145839.GZ2573@alvherre.pgsql>
 <CA+Tgmoaqmo-eSyBQu996Lko7AWu-Yij-Tjd1Zi-LM3UJmU2MKQ@mail.gmail.com>
 <20151002185941.GE2573@alvherre.pgsql>
 <CA+Tgmob_NQhUgbDCFEWBy6CanVG7mo5FuzPGR1_q9=7Gv+Q0cw@mail.gmail.com>
 <5622BF9D.2010409@2ndquadrant.com>
 <CA+TgmoYNUAt-7fJboXGOVcXmS_OeddhL+r5Tq3qDebdhJHR8mA@mail.gmail.com>
 <20151020190522.GT3391@alvherre.pgsql>
 <20151027180759.GG240637@alvherre.pgsql>
 <CAHGQGwEsKDoYFarJjQ4dvH2ZiDxxK0ZcBP4cV2ahdje5pRW2JA@mail.gmail.com>
 <20151116214338.GD614468@alvherre.pgsql>
Cc: Robert Haas <robertmhaas@gmail.com>, oonishitk@nttdata.co.jp,
 pgsql-docs <pgsql-docs@postgresql.org>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
From: Petr Jelinek <petr@2ndquadrant.com>
Message-ID: <56606BA9.1050606@2ndquadrant.com>
Date: Thu, 3 Dec 2015 17:19:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151116214338.GD614468@alvherre.pgsql>
Content-Type: multipart/mixed; boundary="------------030508000800050700000501"
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

This is a multi-part message in MIME format.
--------------030508000800050700000501
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 2015-11-16 22:43, Alvaro Herrera wrote:
> I paraphrase Fujii Masao, who wrote:
>
>> 1. Start the master and standby servers with track_commit_timestamp enabled.
>> 2. Disable track_commit_timestamp in the master and restart the master server.
>> 3. Run checkpoint in the master.
>> 4. Run restartpoint in the standby after the checkpoint WAL record generated
>> 5. Restart the standby server.
>> 6. Enable track_commit_timestamp in the master and restart the master server.
>> 7. Disable track_commit_timestamp in the master and restart the master server.
>
>> What I think strange is that pg_last_committed_xact() behaves differently
>> in #2, #5, and #7 though the settings of track_commit_timestamp are same
>> in both servers, i.e., it's disabled in the master but enabled in the standby.
>
> Interesting, thanks.  You're right that this behaves oddly.
>
> I think in order to fix these two points (#5 and #7), we need to make
> the standby not honour the GUC at all, i.e. only heed what the master
> setting is.
>
>> 8. Promote the standby server to new master.
>>      Since committs is still inactive even after the promotion,
>>      pg_last_committed_xact() keeps causing an ERROR though
>>      track_commit_timestamp is on.
>>
>> I was thinking that whether committs is active or not should depend on
>> the setting of track_commit_timestamp *after* the promotion.
>> The behavior in #8 looked strange.
>
> To fix this problem, we can re-run StartupCommitTs() after recovery is
> done, this time making sure to honour the GUC setting.
>
> I haven't tried the scenarios we fixed with the previous round of
> patching, but this patch seems to close the problems just reported.
> (My next step will be looking over the recovery test framework by
> Michael et al, so that I can apply a few tests for this stuff.)
> In the meantime, if you can look this over I would appreciate it.
>

While this seems good, I'd code it slightly differently. I didn't like 
the addition of new bool when it's not really needed. This brings the 
question if we actually need the BootStrapCommitTs and StartupCommitTs 
functions which really don't do much though.

-- 
  Petr Jelinek                  http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

--------------030508000800050700000501
Content-Type: binary/octet-stream;
 name="committs-activation-fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="committs-activation-fix.patch"

diff --git a/src/backend/access/transam/commit_ts.c b/src/backend/access/transam/commit_ts.c
index 349228d..edb0d2b 100644
--- a/src/backend/access/transam/commit_ts.c
+++ b/src/backend/access/transam/commit_ts.c
@@ -510,7 +510,7 @@ BootStrapCommitTs(void)
 	/*
 	 * Nothing to do here at present, unlike most other SLRU modules; segments
 	 * are created when the server is started with this module enabled. See
-	 * StartupCommitTs.
+	 * ActivateCommitTs.
 	 */
 }
 
@@ -544,13 +544,13 @@ ZeroCommitTsPage(int pageno, bool writeXlog)
  * configuration.
  */
 void
-StartupCommitTs(bool force_enable)
+StartupCommitTs(bool enabled)
 {
 	/*
 	 * If the module is not enabled, there's nothing to do here.  The module
 	 * could still be activated from elsewhere.
 	 */
-	if (track_commit_timestamp || force_enable)
+	if (enabled)
 		ActivateCommitTs();
 }
 
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index f17f834..ee0b959 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -7339,7 +7339,7 @@ StartupXLOG(void)
 	if (standbyState == STANDBY_DISABLED)
 	{
 		StartupCLOG();
-		StartupCommitTs(false);
+		StartupCommitTs(track_commit_timestamp);
 		StartupSUBTRANS(oldestActiveXID);
 	}
 
diff --git a/src/include/access/commit_ts.h b/src/include/access/commit_ts.h
index 3844bb3..f5b3969 100644
--- a/src/include/access/commit_ts.h
+++ b/src/include/access/commit_ts.h
@@ -34,7 +34,7 @@ extern Size CommitTsShmemBuffers(void);
 extern Size CommitTsShmemSize(void);
 extern void CommitTsShmemInit(void);
 extern void BootStrapCommitTs(void);
-extern void StartupCommitTs(bool force_enable);
+extern void StartupCommitTs(bool enabled);
 extern void CommitTsParameterChange(bool xlrecvalue, bool pgcontrolvalue);
 extern void CompleteCommitTsInitialization(void);
 extern void ShutdownCommitTs(void);

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


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

--------------030508000800050700000501--