REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start
Date: 2026-08-27 16:41:49
Message-ID: CALj2ACVAxA9HxvFe8HSspTJ-UO4Aoz=kuQdZBeLrod0gqUxH3g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

REPACK (CONCURRENTLY) starts a decoding bgworker and then waits in
start_repack_decoding_worker() for the worker to set a shared-memory
flag. The wait has no liveness check on the worker itself. If the
worker never reaches that point (e.g., fork failure under memory
pressure, or when BecomeLockGroupMember() returns false, or early exit
before the shm_mq error redirect is set up), the backend waits
indefinitely with no way out other than cancellation. I reproduced
this with an induced fork failure, so I think we need to tighten this
for both PG19 and HEAD branches.

Fix would be to check
GetBackgroundWorkerPid()/WaitForBackgroundWorkerStartup() and error
out when the worker has not started. If okay, I can send a patch.

Thoughts?

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-08-27 16:43:37 REPACK decoding worker startup/teardown differs from parallel.c
Previous Message Nathan Bossart 2026-08-27 16:23:39 REPACK (CONCURRENTLY) doesn't check the table AM