backtrace_functions
Read PG 18 manual ↗This parameter contains a comma-separated list of C function names.
- Type
- string
- Context
- superuser
- Measured default
- Empty string
- Unit
- —
- Metadata snapshot
- 18
Definition PG 18 manual
This parameter contains a comma-separated list of C function names. If an error is raised and the name of the internal C function where the error happens matches a value in the list, then a backtrace is written to the server log together with the error message. This can be used to debug specific areas of the source code.
Backtrace support is not available on all platforms, and the quality of the backtraces depends on compilation options.
Only superusers and users with the appropriate SET privilege can change this setting.
Measured default history
| Version interval | Default |
|---|---|
| 13 – 19 | Empty string |
Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗
How it works
backtrace_functions is a comma-separated list of internal C function names. If an error originates in a listed function, PostgreSQL appends a native backtrace to that error in the server log.
It matches C symbols, not SQL function names. Availability and symbol quality depend on platform, compiler, build flags, debug information, and whether functions were inlined.
The setting can target a narrow failure path without logging stacks for every error. Stack traces can expose implementation detail and increase log volume, so collection should be scoped and protected. Its superuser context permits an authorized session change without a server restart.
Operational considerations
Leaving backtrace_functions 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.
Workload guidance
OLAP: Long analytical runs can amplify backtrace_functions's debug overhead and artifacts. Prefer standard EXPLAIN and statistics first, and isolate any developer experiment from normal users.
OLTP: Do not tune production OLTP with backtrace_functions. Enable it only for a bounded reproduction with an owner, log/disk budget, rollback condition, and evidence-capture plan; restore the default immediately afterward.
SMALL: Keep backtrace_functions at its upstream default. A small host has less spare CPU, disk, connection, and log capacity for developer instrumentation.
Version history 2
- PG 14 → 15changed
- PG 12 → 13added
Related entries
Further reading
Definition snapshot: english-manuals:faaa62e385cecb0ad31da958d22… · English manual source