Hi,
Can somebody confirm or correct what I (think I)'ve gleaned from
the code?
- Commit timestamps are always WAL logged, and so in principle
determinable after the fact (with some amount of effort), regardless
of the track_commit_timestamp setting. (I guess this must have long
been true, to support recovery_target_time.)
- The extra machinery turned on by track_commit_timestamp maintains
a cache of recent ones so they can be efficiently queried from SQL
in normal operation.
? Given a base backup and a bunch of WAL from a cluster that had
track_commit_timestamps turned off, is it possible (in principle?)
to do a PITR with the switch turned on, and have the commit_ts
cache get populated (at least from the transactions encountered
in the WAL)? Could that be done by changing the setting in
postgresql.conf for the recovery, or would it take something more
invasive, like poking the value in pg_control? Or would that just
make something fall over? Would it require dummying up some commit_ts
files first?
Thanks,
-Chap
