On Fri, Oct 2, 2015 at 11:58 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Fujii Masao wrote: > >> What happens if pg_xact_commit_timestamp() is called in standby after >> track_commit_timestamp is disabled in master, DeactivateCommitTs() is >> called and all commit_ts files are removed in standby? I tried that case >> and got the following assertion failure. > > Ah. So the standby needs to keep the module activated if it's enabled > locally, even when it receives a message that the master turned it off. > Here's a patch.
I'm afraid that this behavior might confuse the users. Please imagine the following scenario. 1. start up the server with track_commit_timestamp disabled 2. run several transactions 3. shut down the server with immediate mode 4. restart the server with track_commit_timestamp enabled 5. run "SELECT pg_last_committed_xact()" 6. run "SELECT pg_xact_commit_timestamp(xid) FROM pg_last_committed_xact()" 7. restart the server 8. run "SELECT pg_last_committed_xact()" Firstly, in #5, pg_last_committed_xact() returns the XID and timestamp of the last transaction which was executed in #2 (i.e., while track_commit_timestamp was disabled). This is confusing. I think that both pg_last_committed_xact() and pg_xact_commit_timestamp() should return only the transaction which was executed with track_commit_timestamp enabled. Secondly, SELECT query in #6 returns NULL. This means that pg_xact_commit_timestamp() may not handle the transaction which pg_last_committed_xact() handles. This is also confusing. Finally, in #8, pg_last_committed_xact() returns NULL while it returned non-NULL before the restart. This is also confusing. 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
