On Tue, Nov 17, 2015 at 6:43 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> 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.
Sorry for not reviewing the patch before you push it... In HEAD, I ran very simple test case: 1. enable track_commit_timestamp 2. start the server 3. run some transactions 4. execute pg_last_committed_xact() -- returns non-null values 5. shutdown the server with immdiate mode 6. restart the server -- crash recovery happens 7. execute pg_last_committed_xact() The last call of pg_last_committed_xact() returns NULL values, which means that the xid and timestamp information of the last committed transaction disappeared by crash recovery. Isn't this a bug? Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
