Parameter · Replication / Sending Servers
track_commit_timestamp
Collects transaction commit time.
- Default:
off - Type: bool
- Applies: Restart required
In plain words
When on, PostgreSQL remembers when each transaction committed. You can then ask "when was the row version with this xmin committed?" Logical replication uses it on a subscriber to detect and report conflicts with changes made locally.
It costs a little extra I/O and a small on-disk area. Off by default.
For DBAs and operators
Timestamps are stored in an SLRU under $PGDATA/pg_commit_ts/ (cache size: commit_timestamp_buffers, PostgreSQL 17+), 10 bytes per transaction, truncated together with the commit log as XIDs are frozen. Only transactions committed while the setting was on have a timestamp.
SELECT pg_xact_commit_timestamp(xmin), * FROM orders WHERE id = 42;
SELECT * FROM pg_last_committed_xact();Without it: ERROR: could not get commit timestamp data HINT: Make sure the configuration parameter "track_commit_timestamp" is set.
PostgreSQL 18 subscribers detect and log conflicts such as update_origin_differs and delete_origin_differs (counted in pg_stat_subscription_stats) only when track_commit_timestamp is on on the subscriber. Bidirectional / multi-master tools also rely on it.
How to change it
Change in postgresql.conf or ALTER SYSTEM, then restart the server.
See it in context
Logical replication Commit log, hint bits and subtransactions SLRU caches
Related parameters
commit_timestamp_buffers max_logical_replication_workers wal_level