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

On Mon, Sep 14, 2026 at 2:00 AM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> I'm not sure this should be considered a bug. AFAICS the problem happens
> due to calling proc_exit() directly, i.e. exiting the worker w/o sending a
> message via the error queue. (If an error was sent,
> ConditionVariableSleep() should process it and raise ERROR in the backend
> running REPACK.)
>
> However, the REPACK worker does not call proc_exit() directly.

Yes, agreed: the direct proc_exit() test alone didn't establish a bug. I
checked whether error delivery can actually fail after attachment.

There is a path in mq_putmessage(): an interrupt while blocked on the full
error queue makes recursive FATAL output detach it via pq_mq_busy. The FATAL
reaches the server log, but not the REPACK backend.

I reproduced this on v4 plus only the attached repack_worker.c test hooks,
built with injection points and server-wide client_min_messages=debug1:

1. For queue_t with a primary key, attach the standard wait action:

create extension injection_points;
select injection_points_attach(
'repack-worker-before-snapshot-export', 'wait');

2. In another session run repack (concurrently) queue_t. When the worker waits
at InjectionPoint/repack-worker-before-snapshot-export, SIGSTOP the REPACK
backend and run:

select injection_points_wakeup(
'repack-worker-before-snapshot-export');

3. Repeat until the worker waits at IPC/MessageQueuePutMessage:

select pg_logical_emit_message(false, 'repack-queue-test',
repeat('x', 15 * 1024 * 1024));

4. Run select pg_terminate_backend(worker_pid), wait for the worker to exit,
then SIGCONT the REPACK backend.

With v4, REPACK remains active in RepackWorkerExport. With the patch, it
returns 55000, "REPACK worker exited before exporting requested data".

So the bug is real and the worker-status check is needed. The direct
proc_exit() test was only an incomplete reproducer. Thanks for making me
check it.

Nik