Skip to content

debug_discard_caches

debug_discard_caches — Aggressively flush system caches for debugging purposes. Observed in PG14–19 Beta 3; its last measured boot default is 0 in PG19 Beta 3, with superuser context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.
Note

Fact — official short description: “Aggressively flush system caches for debugging purposes.”

Identity

Type , Valueinteger
Upstream pg_settings type
Context , Valuesuperuser
Settable at runtime by a superuser
Unit , Value
Raw unit
Range , Value00
Raw limits in the last observed version
Enum values , Value
— for non-enum types
Category , ValueDeveloper Options
Upstream classification
Latest boot value , Value0
0

Lifecycle

Fact Value
First observed PG14
Present in PG14–19 Beta 3
Removed in No
Introduction commit 6201fa3c166f — Rename debug_invalidate_system_caches_always to debug_discard_caches.
Commit date 2021-07-13
Discussion thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions Raw boot_val Unit Human value
PG14–19 Beta 3 0 0

How it works

debug_discard_caches invalidates system-catalog cache entries at the earliest opportunity; higher values recurse the behavior. Nonzero values make the server extremely slow to expose cache invalidation bugs.

It is supported only in builds compiled with DISCARD_CACHES_ENABLED, automatically associated with –enable-cassert. Production builds keep zero and reject attempts to change it.

The parameter tests correctness under pathological cache churn. It does not flush shared_buffers, the operating-system page cache, or ordinary query result caches. Its superuser context permits an authorized session change without a server restart.

Tuning advice

Tip

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

Workload Guidance
OLTP Do not tune production OLTP with debug_discard_caches. Enable it only for a bounded reproduction with an owner, log/disk budget, rollback condition, and evidence-capture plan; restore the default immediately afterward.
OLAP Long analytical runs can amplify debug_discard_caches’s debug overhead and artifacts. Prefer standard EXPLAIN and statistics first, and isolate any developer experiment from normal users.
Small nodes Keep debug_discard_caches at its upstream default. A small host has less spare CPU, disk, connection, and log capacity for developer instrumentation.

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

Common pitfalls

  • Leaving debug_discard_caches enabled after the bounded diagnostic or recovery task.
  • Running the experiment on the only copy of production data.
  • Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
  • Treating a server that merely starts or completes a query as proof that data and behavior are correct.

ignore_system_indexes · shared_buffers · debug_parallel_query · allow_system_table_mods

References