transaction_buffers

transaction_buffers — Sets the size of the dedicated buffer pool used for the transaction status cache. Observed in PG17–19 Beta 3; its last measured boot default is 0 B (0 × 8kB) in PG19 Beta 3, with postmaster context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Sets the size of the dedicated buffer pool used for the transaction status cache.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value8kB: Raw unit
Range , Value0 – 131072: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueResource Usage / Memory: Upstream classification
Latest boot value , Value0: 0 B (0 × 8kB)

Lifecycle

Fact	Value
First observed	PG17
Present in	PG17–19 Beta 3
Removed in	No
Introduction commit	`53c2a97a9266` — Improve performance of subsystems on top of SLRU
Commit date	2024-02-28
Discussion	thread 1 · thread 2

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG17–19 Beta 3	`0`	`8kB`	0 B (0 × 8kB)

How it works

transaction_buffers allocates a dedicated shared buffer pool for pg_xact, which caches transaction commit-status pages. This is real startup shared memory, not a planner estimate.

Zero is an automatic-sizing request: PostgreSQL derives shared_buffers/512 and clamps it between 16 and 1024 blocks. The unit is BLCKSZ blocks, normally 8kB.

A larger cache can reduce SLRU read/write churn for unusually heavy use of the underlying feature, but it permanently consumes shared memory and does not increase the feature’s logical capacity. Its postmaster context fixes the value at server start; changing it requires a restart.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Leave transaction_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.
OLAP	Analytical workload labels alone do not justify changing transaction_buffers; tune only when the underlying transaction-state facility, not table scans, is the measured bottleneck.
Small nodes	Keep transaction_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.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG17–19 Beta 3 unmodified; OLAP: PG17–19 Beta 3 unmodified; CRIT: PG17–19 Beta 3 unmodified; TINY: PG17–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Changing transaction_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.

subtransaction_buffers · shared_buffers · commit_timestamp_buffers