Nikolay Samokhvalov <[email protected]> wrote: > On Mon, Sep 7, 2026 at 12:15 PM Bharath Rupireddy > <[email protected]> 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/cam527d9a7fbxjn7a3w2vapq0gojm7tnudfmh1uwjitgfi2k...@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
