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: 
 <CAM527d8cF-6azsRWOPaOUCmsdgMG=ene7-st91_NM7v0q3uLLg@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>
Comments: In-reply-to Nikolay Samokhvalov <nik@postgres.ai>
   message dated "Sun, 13 Sep 2026 11:37:49 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Mon, 14 Sep 2026 11:00:14 +0200
Message-ID: <19643.1789376414@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/19643.1789376414%40localhost>
Precedence: bulk

Nikolay Samokhvalov <nik@postgres.ai> wrote:

> On Mon, Sep 7, 2026 at 12:15 PM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> > After thinking more about this, I simplified the handling. There are two
> > things the backend needs to wait for. First, for the worker to come up =
and
> > attach to the error message queue. Second, for the worker to set up the
> > logical decoding machinery before it waits for snapshot export. The fir=
st
> > wait catches fork failures and worker startup issues. I used similar lo=
gic
> > to what parallel.c uses for this. The second wait catches failures that
> > happen after the worker starts up and attaches to the error queue but
> > before it finishes setting up the logical decoding machinery. I kept the
> > shared memory initialized flag with the CV wait as-is for this.
>=20
> =C3=81lvaro pointed me here from my thread:
> https://postgr.es/m/CAM527d9A7FBXJn7A3w2VAPq0Gojm7tnUDFMh1uwJitGfi2kNeQ@m=
ail.gmail.com
>=20
> My AI harness tested v4. Silent worker exits still hang three
> post-attachment waits. Mihail raised snapshot/replay liveness in
> December 2025.
>=20
> Snapshot repro on a test build configured with --enable-injection-points,
> with v4 plus only the attached patch's test support:
>=20
>     create extension injection_points;
>     create table t (i int primary key);
>     insert into t select generate_series(1, 100);
>     set statement_timeout =3D '2s';
>     select injection_points_attach(
>       'repack-worker-before-snapshot-export',
>       'injection_points', 'injection_exit', null);
>     repack (concurrently) t;
>=20
> This times out after worker exit. The attached patch applies atop v4.

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 mess=
age
via the error queue. (If an error was sent, ConditionVariableSleep() should
process it and raise ERROR in the backend running REPACK.) However, the REP=
ACK
worker does not call proc_exit() directly.

(parallel.c tries to guard against worker calling proc_exit() and it seems =
to
have an issue, but it's a separate topic [1])

[1] https://www.postgresql.org/message-id/64338.1788881902%40localhost

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