Re: BUG #19530: Crash (SIGSEGV/SIGBUS) in parallel B-tree index vacuum during plain VACUUM

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: webmaster(at)algedi(dot)pl, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19530: Crash (SIGSEGV/SIGBUS) in parallel B-tree index vacuum during plain VACUUM
Date: 2026-06-22 09:51:23
Message-ID: CANWCAZaQ8sxPy2w0zWExnJXsK9t0y4AAxhENz3mhaO1Z2wdFoA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Jun 22, 2026 at 3:19 PM PG Bug reporting form
<noreply(at)postgresql(dot)org> 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/VI0PR07MB10718A4DC292E068C51404AB2974EA@VI0PR07MB10718.eurprd07.prod.outlook.com)
> 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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Matheus Alcantara 2026-06-22 10:18:46 Re: BUG #19480: PL/Python SRF crashes (SIGSEGV) when function is replaced mid-iteration: use-after-free in PLy_funct
Previous Message Michael Paquier 2026-06-22 08:28:58 Re: BUG #19520: PANIC when concurrently manipulating stored procedures with pg_stat_statements and track_functions =