From: Antonin Houska <ah@cybertec.at>
To: Nikolay Samokhvalov <nik@postgres.ai>
cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
    Masahiko Sawada <sawada.mshk@gmail.com>,
    Nathan Bossart <nathandbossart@gmail.com>,
    PostgreSQL-development <pgsql-hackers@postgresql.org>,
    alvherre@kurilemu.de
Subject: Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding
 worker fails to start
In-reply-to: 
 <CAM527d-bUOdoZezwXuhpjjwm-cB6q_m_YmJyVusgTPKSkohGJA@mail.gmail.com>
References: 
 <CALj2ACVAxA9HxvFe8HSspTJ-UO4Aoz=kuQdZBeLrod0gqUxH3g@mail.gmail.com>
 <apBqNzV4N2CKa1ug@nathan>
 <CALj2ACUpxBdkAfvfT4=DsQ4k5Faz7W9Sqk27j+Y4HWexPSvUdA@mail.gmail.com>
 <27780.1788172295@localhost>
 <CALj2ACVoM4cd5bhOhqP+qqaetL9gWvChCFEoym6GZHHbz-faJw@mail.gmail.com>
 <CAD21AoDfyYqXH8wG2W=9j4T7yFrPvyM7tbGkvxNAMgUCP3w44w@mail.gmail.com>
 <CALj2ACVxb8rWTie8xBdXUHhaQosomHjQHRUqr2VX+Fx0qFXTiw@mail.gmail.com>
 <7564.1788851851@localhost>
 <CALj2ACVCmocWuM8HTVdfE-AcgcO3wP5K6gFMh5CkDtbv4y2O9g@mail.gmail.com>
 <CAM527d8cF-6azsRWOPaOUCmsdgMG=ene7-st91_NM7v0q3uLLg@mail.gmail.com>
 <19643.1789376414@localhost>
 <CAM527d-bUOdoZezwXuhpjjwm-cB6q_m_YmJyVusgTPKSkohGJA@mail.gmail.com>
Comments: In-reply-to Nikolay Samokhvalov <nik@postgres.ai>
   message dated "Mon, 14 Sep 2026 18:31:47 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26323.1789468000.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 15 Sep 2026 12:26:40 +0200
Message-ID: <26324.1789468000@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/26324.1789468000%40localhost>
Precedence: bulk

Nikolay Samokhvalov <nik@postgres.ai> wrote:

> On Mon, Sep 14, 2026 at 2:00 AM Antonin Houska <ah@cybertec.at> wrote:
> > I'm not sure this should be considered a bug. AFAICS the problem happe=
ns
> > due to calling proc_exit() directly, i.e. exiting the worker w/o sendi=
ng a
> > message via the error queue. (If an error was sent,
> > ConditionVariableSleep() should process it and raise ERROR in the back=
end
> > 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 fu=
ll
> error queue makes recursive FATAL output detach it via pq_mq_busy. The F=
ATAL
> reaches the server log, but not the REPACK backend.
> =

> I reproduced this on v4 plus only the attached repack_worker.c test hook=
s,
> built with injection points and server-wide client_min_messages=3Ddebug1=
:
> =

> 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 R=
EPACK
>    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 e=
xit,
>    then SIGCONT the REPACK backend.
> =


I wonder if you forgot to attach some files (I don't see the queue_t table=
 in
the scripts you posted earlier), but I think I was able to reproduce the
problem using the instructions above.

IMO the problem is that the backend ignores the SHM_MQ_DETACHED state in
ProcessRepackMessages(). If all the messages in the queue have severity lo=
wer
than ERROR, the worker just processes them and continues waiting for the
worker to export the snapshot. However, as the worker is gone, there's no =
way
to wake the backend up.

Patch 0002 in [1] should fix that.

[1] https://www.postgresql.org/message-id/CALj2ACWJsOG0-2SQUxBXG9ULFs_GJpe=
Vhhmp8AHf8c9iKDjMXA%40mail.gmail.com

Thanks for testing!

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com