Coredump Filters

Coredump filters let an operator request a diagnostic core file when ProxySQL reaches a selected source location. Use them for a narrowly scoped investigation when ProxySQL support or the source for the exact build provides the filename and line number to target.

Core files can be large and can contain queries, credentials, and in-memory application data. Store them on a restricted filesystem with enough free space, keep the rate limits conservative, and remove the filters and core files when the investigation ends.

Supported Platforms

Filtered core generation is supported on Linux for x86-32, x86-64, ARM, and MIPS builds. On unsupported platforms, ProxySQL logs a warning and does not create the file.

Configuration and Runtime Tables

The coredump_filters configuration table holds case-sensitive filename and line-number pairs:

CREATE TABLE coredump_filters (
    filename VARCHAR NOT NULL,
    line INT NOT NULL,
    PRIMARY KEY (filename, line)
)

Add only a location that contains a coredump trigger in the exact ProxySQL build being diagnosed. For example, use the following only if that build’s source or ProxySQL support confirms this location:

INSERT INTO coredump_filters (filename, line)
VALUES ('lib/mysql_data_stream.cpp', 485);

runtime_coredump_filters has the same schema and shows the active in-memory set. Loading replaces the current runtime set with the rows in coredump_filters:

LOAD COREDUMP TO RUNTIME;

SELECT filename, line
FROM runtime_coredump_filters
ORDER BY filename, line;

The accepted aliases are:

• LOAD COREDUMP FROM MEMORY
• LOAD COREDUMP FROM MEM
• LOAD COREDUMP TO RUN

There is no released SAVE COREDUMP command or disk/config copy of this table. coredump_filters is main-memory-only and its rows are lost on every restart. Reinsert or provision the desired rows after each restart, then run LOAD COREDUMP TO RUNTIME. Filters are local to each ProxySQL instance and are not automatically synchronized across a cluster.

See Configuration Tables and Admin Commands for the canonical table and command reference.

Rate Limits

Two dynamic Admin variables limit file generation:

Assignments take effect immediately:

SET admin-coredump_generation_threshold = 3;
SET admin-coredump_generation_interval_ms = 30000;

The interval limit does not increase the threshold. Once the threshold is reached, a matching location can still be logged but no additional core file is written. In v3.0.10, every LOAD COREDUMP TO RUNTIME (or alias) resets both the generated-file count and the last-generation timestamp while replacing the filter set. A restart also clears that state. Reloading filters can therefore permit another set of large, sensitive core files; confirm the limits and available disk space before every load.

Core Files and Cleanup

A matching active location writes a compressed file named core.<pid>.<counter> in the ProxySQL process’s current working directory. Ensure the service account can write there, monitor free space while the filter is active, and use a debugger that matches the ProxySQL binary and build symbols.

Remove the runtime filters after collection:

DELETE FROM coredump_filters;
LOAD COREDUMP TO RUNTIME;

SELECT * FROM runtime_coredump_filters;

An empty result confirms that no source-location triggers are active. Remove sensitive core files securely after the investigation.

Troubleshooting