select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / RESOURCE USAGE

commit_timestamp_buffers

Read PG 18 manual ↗

Specifies the amount of memory to use to cache the contents of pg_commit_ts (see Table 66.1).

Type
integer
Context
postmaster
Measured default
0 B (0 × 8kB)
Unit
8kB
Metadata snapshot
18

Definition PG 18 manual

Specifies the amount of memory to use to cache the contents of pg_commit_ts (see Table 66.1). If this value is specified without units, it is taken as blocks, that is BLCKSZ bytes, typically 8kB. The default value is 0, which requests shared_buffers/512 up to 1024 blocks, but not fewer than 16 blocks. This parameter can only be set at server start.

Measured default history
Version intervalDefault
17 – 190 B (0 × 8kB)
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

commit_timestamp_buffers allocates a dedicated startup-time shared buffer pool for pages in pg_commit_ts, the SLRU area used when commit timestamp tracking is enabled.

A configured zero is an automatic sizing request, not zero memory: PostgreSQL derives shared_buffers/512, clamps it to at least 16 and at most 1024 blocks, and allocates the result at server start.

The cache can reduce pg_commit_ts reads but does not enable commit timestamp collection; track_commit_timestamp is the separate functional switch. Increasing it consumes real shared memory. Its postmaster context fixes the value at server start; changing it requires a restart.

Operational considerations

Changing commit_timestamp_buffers without applying its documented unit and configuration context.

Optimizing an isolated benchmark while ignoring concurrent aggregate resource use.

Assuming a configured value guarantees operating-system or storage behavior.

Failing to retest startup, failover, and workload latency after the change.

Workload guidance

OLAP: Analytical workload labels alone do not justify changing commit_timestamp_buffers; tune only when the underlying transaction-state facility, not table scans, is the measured bottleneck.

OLTP: Leave commit_timestamp_buffers at automatic or upstream sizing unless SLRU-specific I/O and contention prove this cache is undersized. A larger number consumes shared memory for the entire server lifetime.

SMALL: Keep commit_timestamp_buffers at its default on a small host. Moving scarce shared memory into an internal cache without direct evidence can reduce room for more valuable caches and processes.

Version history 2
  1. PG 17 → 18changed
  2. PG 16 → 17added

Related entries

Further reading

Definition snapshot: english-manuals:32a0459469434f1b31789b2b42e… · English manual source