| 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
| 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 = |