Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19530: Crash (SIGSEGV/SIGBUS) in parallel B-tree index vacuum
 during plain VACUUM
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: webmaster@algedi.pl
Reply-To: webmaster@algedi.pl, pgsql-bugs@lists.postgresql.org
Date: Sun, 21 Jun 2026 21:38:09 +0000
Message-ID: <19530-c1575dd3b1c8a286@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19530-c1575dd3b1c8a286%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19530
Logged by:          Maciej
Email address:      webmaster@algedi.pl
PostgreSQL version: 17.7
Operating system:   FreeBSD 14.4-RELEASE, x86-64
Description:       =20

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=3Dposix, huge_pages=3Dtry.
  max_parallel_workers=3D8, max_parallel_maintenance_workers=3D4,
max_parallel_workers_per_gather=3D4. Extensions: pg_stat_statements, pg_trg=
m,
unaccent,
  plpgsql only =E2=80=94 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 =E2=80=94 i.e. parallel index vacuum, not parallel que=
ry. The
  trigger is a scheduled VACUUM (SKIP_DATABASE_STATS, VERBOSE, ANALYZE) run
via vacuumdb over several large tables, each carrying many (~10=E2=80=9330)=
 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/VI0PR07MB10718A4DC292E068C51404AB297=
4EA@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.

  Workaround:
  Setting max_parallel_maintenance_workers =3D 0 (sequential index vacuumin=
g)
appears to stop the crashes (observation ongoing).