Date: Thu, 27 Aug 2026 11:47:51 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
	=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@kurilemu.de>
Subject: Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding
 worker fails to start
Message-ID: <apBqNzV4N2CKa1ug@nathan>
References: 
 <CALj2ACVAxA9HxvFe8HSspTJ-UO4Aoz=kuQdZBeLrod0gqUxH3g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CALj2ACVAxA9HxvFe8HSspTJ-UO4Aoz=kuQdZBeLrod0gqUxH3g@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/apBqNzV4N2CKa1ug%40nathan>
Precedence: bulk

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