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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start
Date: 2026-08-27 16:47:51
Message-ID: apBqNzV4N2CKa1ug@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 27, 2026 at 09:41:49AM -0700, Bharath Rupireddy wrote:
> 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.

Oops, I just concurrently reported this [0]. Note that teardown can
deadlock, too.

[0] https://postgr.es/m/apBpOVZOyqrakEr_%40nathan

--
nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-08-27 16:52:22 Re: Fix REPACK with WITHOUT OVERLAPS replica identity indexes
Previous Message Jingtang Zhang 2026-08-27 16:46:01 Re: Allow aggressive VACUUM to freeze without a cleanup lock