Re: [HACKERS] max_worker_processes on the standby

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