select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / DEVELOPER OPTIONS

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 intervalDefault
13 – 19Empty string
Analysis & operational context

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
  1. PG 14 → 15changed
  2. PG 12 → 13added

Related entries

Further reading

Definition snapshot: english-manuals:faaa62e385cecb0ad31da958d22… · English manual source