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

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Nikolay Samokhvalov <nik(at)postgres(dot)ai>
Cc: Antonin Houska <ah(at)cybertec(dot)at>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, alvherre(at)kurilemu(dot)de
Subject: Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start
Date: 2026-09-15 08:38:00
Message-ID: CALj2ACWJsOG0-2SQUxBXG9ULFs_GJpeVhhmp8AHf8c9iKDjMXA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sun, Sep 13, 2026 at 11:38 AM Nikolay Samokhvalov <nik(at)postgres(dot)ai> wrote:
>
> My AI harness tested v4. Silent worker exits still hang three
> post-attachment waits. Mihail raised snapshot/replay liveness in
> December 2025.
>
> As far as I can see, the current uncommitted patches cover overall 5 cases:
>
> - startup before queue attach: Bharath v4
> - full error queue teardown: Bharath v4
> - silent exit after attach, before initialization: attached patch
> - silent exit before snapshot export: attached patch
> - silent exit before replay export: attached patch

Thanks a lot for sharing these additional corner cases. The first two
and the later three are separate problems, but I agree we need to fix
them all. I spent some time reading how parallel query handles these
and ended up with the attached patches.

0001 fixes the first two cases: the backend now waits for the worker
to attach to the error message queue before waiting for decoding to be
initialized, and detaches from that queue before waiting for the
worker to exit.

0002 fixes the three silent exit cases reported above: the worker now
sends a Terminate message as its last act, so the queue going away
without it means the worker left with the work unfinished.

0003 adds tests using injection points. I reused the one shared
upthread and just added cases for the hang and the deadlock that 0001
fixes. I don't intend to get this in unless others think it's
necessary.

0004 is a cleanup: the backend left the flag saying there are worker
messages to process set even when there was no worker to read messages
from, so every later interrupt check went looking for messages for
nothing.

Thoughts?

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v5-0001-Fix-hang-and-deadlock-in-concurrent-REPACK-worker.patch application/octet-stream 9.5 KB
v5-0002-Detect-premature-exit-of-the-REPACK-decoding-work.patch application/octet-stream 7.3 KB
v5-0003-Add-tests-for-a-REPACK-decoding-worker-that-goes-.patch application/octet-stream 16.7 KB
v5-0004-Clear-the-REPACK-message-flag-when-there-is-nothi.patch application/octet-stream 2.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Henri GASC 2026-09-15 08:44:03 Re: [SQL/PGQ] Native executor for Graph query
Previous Message vignesh C 2026-09-15 08:30:30 Re: Distinguish publication exclusions in object addresses