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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
diff --git a/src/backend/access/transam/commit_ts.c b/src/backend/access/transam/commit_ts.c
index 349228d..03d9743 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 honour_config, bool force_enable)
{
/*
* 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 ((honour_config && track_commit_timestamp) || force_enable)
ActivateCommitTs();
}
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 08d1682..0ed6822 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -6567,7 +6567,7 @@ StartupXLOG(void)
* maintained during recovery and need not be started yet.
*/
StartupCLOG();
- StartupCommitTs(ControlFile->track_commit_timestamp);
+ StartupCommitTs(false, ControlFile->track_commit_timestamp);
StartupSUBTRANS(oldestActiveXID);
/*
@@ -7336,7 +7336,7 @@ StartupXLOG(void)
if (standbyState == STANDBY_DISABLED)
{
StartupCLOG();
- StartupCommitTs(false);
+ StartupCommitTs(true, false);
StartupSUBTRANS(oldestActiveXID);
}
diff --git a/src/include/access/commit_ts.h b/src/include/access/commit_ts.h
index 3844bb3..991dd42 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 honour_config, bool force_enable);
extern void CommitTsParameterChange(bool xlrecvalue, bool pgcontrolvalue);
extern void CompleteCommitTsInitialization(void);
extern void ShutdownCommitTs(void);
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
