logical_decoding_work_mem

logical_decoding_work_mem — Sets the maximum memory to be used for logical decoding. Observed in PG13–19 Beta 3; its last measured boot default is 64 MiB in PG19 Beta 3, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Sets the maximum memory to be used for logical decoding.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , ValuekB: Raw unit
Range , Value64 – 2147483647: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueResource Usage / Memory: Upstream classification
Latest boot value , Value65536: 64 MiB

Lifecycle

Fact	Value
First observed	PG13
Present in	PG13–19 Beta 3
Removed in	No
Introduction commit	`cec2edfa7859` — Add logical_decoding_work_mem to limit ReorderBuffer memory usage.
Commit date	2019-11-16
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG13–19 Beta 3	`65536`	`kB`	64 MiB

How it works

logical_decoding_work_mem is the real memory threshold for one logical decoding stream before decoded changes are written to local temporary files. It is independent of ordinary query work_mem.

Each replication connection uses one such buffer, and concurrency is bounded by replication sender capacity rather than client sessions. Large in-progress transactions can spill and later be reread.

Raising the threshold can reduce serialization I/O for logical replication, but the cluster memory budget must multiply it by concurrent decoding streams and include output-plugin memory outside this accounting. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

Tip

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

Workload	Guidance
OLTP	Change logical_decoding_work_mem only after identifying the corresponding resource bottleneck under concurrency. Budget total memory, I/O, disk, or kernel capacity rather than optimizing one process in isolation.
OLAP	Benchmark logical_decoding_work_mem with representative bulk and scan phases. Include sustained throughput, spill/writeback, and interference with other sessions, not only one operation’s elapsed time.
Small nodes	Keep logical_decoding_work_mem conservative on a small host and prefer the upstream default when evidence is weak. A setting copied from a large server can consume a disproportionate share of resources.

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: PG13–19 Beta 3 unmodified; OLAP: PG13–19 Beta 3 unmodified; CRIT: PG13–19 Beta 3 unmodified; TINY: PG13–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

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

work_mem · max_wal_senders · max_replication_slots · debug_logical_replication_streaming · temp_file_limit