Chapman Flack wrote: > 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.)
Right. > - 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. Yes. > ? 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? I don't remember if this is explicitly supported, but yeah AFAIR it should work to just start the "promoted standby" (in your case just a recovered backup) on after setting the option in postgresql.conf. This is because StartupCommitTs() activates the commit_ts module just before starting recovery. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
