serializable_buffers

serializable_buffers — Sets the size of the dedicated buffer pool used for the serializable transaction cache. Observed in PG17–19 Beta 3; its last measured boot default is 256 KiB (32 × 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 serializable transaction cache.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuepostmaster: Requires a server restart
Unit , Value8kB: Raw unit
Range , Value16 – 131072: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueResource Usage / Memory: Upstream classification
Latest boot value , Value32: 256 KiB (32 × 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	`32`	`8kB`	256 KiB (32 × 8kB)

How it works

serializable_buffers allocates a dedicated shared buffer pool for pg_serial, which caches serializable-transaction state. This is real startup shared memory, not a planner estimate.

The configured block count is allocated at server start. 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 serializable_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 serializable_buffers; tune only when the underlying transaction-state facility, not table scans, is the measured bottleneck.
Small nodes	Keep serializable_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 serializable_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.

shared_buffers · max_connections · max_pred_locks_per_transaction