Autovacuum worker SIGSEGV after PostgreSQL 13→14 upgrade when extension is loaded via shared_preload_libraries

Environment

PostgreSQL upgraded in-place from 13.5 to 14.2 on Ubuntu 20.04 LTS. A third-party C extension (installed from distro package and also a site-built variant) is listed in shared_preload_libraries and the cluster runs on a 16-core VM with 64GB RAM. Autovacuum runs concurrently on several large tables with high update churn.

Symptoms

Random autovacuum worker processes crash with SIGSEGV while performing VACUUM operations on large tables. Crashes occur a few minutes after autovacuum starts for a given table; normal client sessions remain connected but some background maintenance stops running. The pattern started immediately after the PostgreSQL upgrade and affects tables with frequent updates.

Observations

Postgres log shows process terminated by signal 11 (Segmentation fault) with a backtrace pointing into a symbol exported by the third-party extension (the backtrace includes extension functions called from a background worker/autovacuum stack). core dumps were collected from the host. Restarting the server clears immediate crash activity; removing the extension name from shared_preload_libraries and restarting the cluster prevents further autovacuum SIGSEGVs. Loading the extension into a database session (CREATE EXTENSION) and invoking extension functions manually in a normal backend does not reproduce the crash.

Already attempted

Collected core dumps and matching server symbols. Disabled the extension by removing it from shared_preload_libraries and restarted PostgreSQL — autovacuum no longer crashes. Rebuilt the extension from source against PostgreSQL 14 headers and reinstalled; when present in shared_preload_libraries the crash returned on staging under load. Ran vacuum manually as superuser with the extension loaded (but not preloaded at server start) — manual vacuums complete without segfault. Enabled extra logging and ran with log_min_messages=DEBUG5 to capture initialization order; no additional errors recorded prior to crashes.

Question

What causes autovacuum workers to segfault only when this extension is preloaded at server start, and what are safe remediation steps to restore background maintenance without removing the extension entirely?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 2d ago• Trouble ID

Most likely causes

Extension uses global/static state not initialized safely across forked background processes, causing memory corruption. 90%

Extension init/register hooks call non-SPI-safe functions or allocate shared memory incorrectly when invoked in autovacuum process context. 70%

Extension interacts with system libraries that changed behavior across OS or compiler versions (allocator or thread-safety differences). 25%

Summary

Behavior indicates the extension is either not safe to be loaded into background worker contexts or compiled against an incompatible server ABI. shared_preload_libraries causes the extension's init code to run in all server processes (including autovacuum background workers). If the extension registers hooks, uses non-backend-safe APIs, assumes a backend-only environment, or relies on global state initialized differently per process, it can corrupt memory or dereference invalid pointers in autovacuum workers. The fact that manual use of the extension in a normal backend is safe suggests the fault is in code paths executed only when loaded at process start (initialization hooks, background-worker registration, or global constructors). A mismatch between extension binary and PostgreSQL server ABI (recompilation required) is also a common root cause after an upgrade.

Suggested Fixes

Diagnostic step 1

Remove the extension from shared_preload_libraries (already tested) to stop crashes — reversible and minimal disruption.

Diagnostic step 2

Rebuild the extension from source against the exact PostgreSQL 14 server headers and link flags used by the running server; test on a staging instance with autovacuum under realistic load before deploying to production.

Diagnostic step 3

If the extension must be preloaded, audit its code (or request vendor audit) for background-worker safe patterns: avoid non-reentrant globals, guard initialization with ProcessIsBackgroundWorker checks, use appropriate memory contexts, and avoid calling backend-only APIs during early init. Run with AddressSanitizer or valgrind in staging to detect memory issues.