public inbox for [email protected]
help / color / mirror / Atom feedBUG #19530: Crash (SIGSEGV/SIGBUS) in parallel B-tree index vacuum during plain VACUUM
2+ messages / 2 participants
[nested] [flat]
* BUG #19530: Crash (SIGSEGV/SIGBUS) in parallel B-tree index vacuum during plain VACUUM
@ 2026-06-21 21:38 PG Bug reporting form <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: PG Bug reporting form @ 2026-06-21 21:38 UTC (permalink / raw)
To: [email protected]; +Cc: [email protected]
The following bug has been logged on the website:
Bug reference: 19530
Logged by: Maciej
Email address: [email protected]
PostgreSQL version: 17.7
Operating system: FreeBSD 14.4-RELEASE, x86-64
Description:
PostgreSQL 17.7 intermittently crashes a parallel maintenance worker during
routine VACUUM, taking the server through automatic crash recovery each
time.
Summary:
Recurring backend / parallel-worker terminations with signal 11 (SIGSEGV)
and signal 10 (SIGBUS). Each crash is followed by "terminating any other
active server processes" and crash recovery (~5 s). It is intermittent:
about 16 process terminations over 5 days, with fully clean days in between;
the same nightly maintenance succeeds on most days. Hardware was checked
and is clean (no MCE/ECC/I/O errors).
Environment:
PostgreSQL 17.7, FreeBSD 14.4-RELEASE, x86-64, physical server, 256 GB
RAM. dynamic_shared_memory_type=posix, huge_pages=try.
max_parallel_workers=8, max_parallel_maintenance_workers=4,
max_parallel_workers_per_gather=4. Extensions: pg_stat_statements, pg_trgm,
unaccent,
plpgsql only — no custom C extensions, no PL/Perl/Python.
What the crashing process was doing:
The crashing process is a parallel maintenance worker. A preserved core
dump shows the process title "parallel worker for PID <leader>", with memory
contexts "BTree Vacuum State" and "AutoVacuum Data" present and no
executor/query state — i.e. parallel index vacuum, not parallel query. The
trigger is a scheduled VACUUM (SKIP_DATABASE_STATS, VERBOSE, ANALYZE) run
via vacuumdb over several large tables, each carrying many (~10–30) btree
indexes, so parallel index vacuuming is engaged. The SIGBUS variant is
consistent with a DSM (POSIX shared memory) problem in the parallel path.
Expected vs actual:
Expected: VACUUM completes normally. Actual: a parallel index-vacuum
worker crashes (SIGSEGV/SIGBUS) and the server goes through crash recovery.
Possibly related:
This appears to reach the same btbulkdelete / btvacuumscan code as the
report "Segmentation fault in PostgreSQL 17.7 during REINDEX TABLE
CONCURRENTLY"
(https://www.postgresql.org/message-id/[email protected]...),
but reached
via the plain-VACUUM index-vacuum path rather than validate_index /
ReindexRelationConcurrently. That suggests the fault is in the (parallel)
B-tree
index-vacuum code, reachable from both paths.
Workaround:
Setting max_parallel_maintenance_workers = 0 (sequential index vacuuming)
appears to stop the crashes (observation ongoing).
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: BUG #19530: Crash (SIGSEGV/SIGBUS) in parallel B-tree index vacuum during plain VACUUM
@ 2026-06-22 09:51 John Naylor <[email protected]>
parent: PG Bug reporting form <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: John Naylor @ 2026-06-22 09:51 UTC (permalink / raw)
To: [email protected]; [email protected]
On Mon, Jun 22, 2026 at 3:19 PM PG Bug reporting form
<[email protected]> wrote:
> PostgreSQL 17.7 intermittently crashes a parallel maintenance worker during
> routine VACUUM, taking the server through automatic crash recovery each
> time.
> What the crashing process was doing:
> The crashing process is a parallel maintenance worker. A preserved core
> dump shows the process title "parallel worker for PID <leader>", with memory
> contexts "BTree Vacuum State" and "AutoVacuum Data" present and no
This doesn't really give us any actionable info. Are you able to get a
backtrace from the core dump?
(Autovacuum in v17 cannot use parallel workers, so I'm not sure where
that came from)
> Possibly related:
> This appears to reach the same btbulkdelete / btvacuumscan code as the
> report "Segmentation fault in PostgreSQL 17.7 during REINDEX TABLE
> CONCURRENTLY"
> (https://www.postgresql.org/message-id/[email protected]...),
> but reached
> via the plain-VACUUM index-vacuum path rather than validate_index /
> ReindexRelationConcurrently. That suggests the fault is in the (parallel)
> B-tree
> index-vacuum code, reachable from both paths.
That operation was writing TIDs to a file, which is not what vacuum
does, and it's not clear from that thread whether there's a bug in the
first place.
--
John Naylor
Amazon Web Services
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-06-22 09:51 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-21 21:38 BUG #19530: Crash (SIGSEGV/SIGBUS) in parallel B-tree index vacuum during plain VACUUM PG Bug reporting form <[email protected]>
2026-06-22 09:51 ` John Naylor <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox