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
