track_commit_timestamp

Definition PG 18 manual

Record commit time of transactions. This parameter can only be set at server start. The default value is off.

How it works

Collects transaction commit time. The value is fixed when the server starts, so changing it requires a restart.

PostgreSQL stores transaction commit timestamps in an auxiliary SLRU so SQL and replication-origin features can query them later. It must be enabled at startup before the history is collected and adds storage/I/O overhead; it cannot reconstruct older timestamps.

Monitor and change track_commit_timestamp together with max_active_replication_origins, max_logical_replication_workers, max_replication_slots. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Changing it on the wrong primary, standby, sender, or subscriber role.

Watching only configured bytes/time instead of actual lag, slot position, and worker state.

Failing over to a node that lacks the old primary's capacity or prerequisites.

Using infinite waits or WAL retention to hide a failed consumer.

Workload guidance

OLAP: Read standbys and logical subscribers often see long queries or large transactions. Put explicit bounds on replay/apply and monitor lag, worker saturation, slot restart_lsn, and conflict cancellations.

OLTP: Size track_commit_timestamp from topology, failover roles, slot/subscription count, and reconnect headroom. Test worst-case primary latency, standby replay, and disk retention before production.

SMALL: Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability.