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 first
> > wait catches fork failures and worker startup issues. I used similar logic
> > 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.
>
> Álvaro pointed me here from my thread:
> https://postgr.es/m/CAM527d9A7FBXJn7A3w2VAPq0Gojm7tnUDFMh1uwJitGfi2kNeQ@mail.gmail.com
>
> My AI harness tested v4. Silent worker exits still hang three
> post-attachment waits. Mihail raised snapshot/replay liveness in
> December 2025.
>
> Snapshot repro on a test build configured with --enable-injection-points,
> with v4 plus only the attached patch's test support:
>
> create extension injection_points;
> create table t (i int primary key);
> insert into t select generate_series(1, 100);
> set statement_timeout = '2s';
> select injection_points_attach(
> 'repack-worker-before-snapshot-export',
> 'injection_points', 'injection_exit', null);
> repack (concurrently) t;
>
> 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 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.
(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
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
