From: Antonin Houska <ah@cybertec.at>
To: Masahiko Sawada <sawada.mshk@gmail.com>
cc: Bharath Rupireddy <bharath.rupireddyforpostgres@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: 
 <CAD21AoDfyYqXH8wG2W=9j4T7yFrPvyM7tbGkvxNAMgUCP3w44w@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>
Comments: In-reply-to Masahiko Sawada <sawada.mshk@gmail.com>
   message dated "Fri, 04 Sep 2026 17:11:07 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32122.1788806780.1@localhost>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 07 Sep 2026 20:46:20 +0200
Message-ID: <32123.1788806780@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/32123.1788806780%40localhost>
Precedence: bulk

Masahiko Sawada <sawada.mshk@gmail.com> wrote:

> +   /*
> +    * Associate the worker's handle with the error queue, just as if it=
 had
> +    * been passed to shm_mq_attach(); we passed NULL there because the =
worke
> +    * did not exist yet. This lets ProcessRepackMessages() notice the w=
orker
> +    * is gone instead of blocking on the queue.
> +    */
> +   shm_mq_set_handle(decoding_worker->error_mqh, decoding_worker->handl=
e);
> +
> =

> The second sentence starting with "This lets ..." is unclear to me.
> ProcessRepackMessage() receives the message with nowait, no?

Although it probably does not break anything if we pass the handle to
shm_mq_set_handle() unnecessarily, I'm thinking if it's necessary for an e=
rror
queue.

AFAIU the purpose of the handle is to realize that it makes no sense to wa=
it
for the background worker to attach to the queue. Once the worker has
attached, the worker's handle is no longer needed to detect that the worke=
r
detached: the already-attached worker itself is supposed to call
shm_mq_detach().

If I use the parallel worker for reference, I think the leader should not =
be
asked (via the PROCSIG_PARALLEL_MESSAGE signal) to read from the error que=
ue
until the worker has attached and redirected its messages to the queue - s=
ee
in ParallelWorkerMain():

	mqh =3D shm_mq_attach(mq, seg, NULL);
	pq_redirect_to_shm_mq(seg, mqh);

Therefore, the leader should not need the worker's handle.


I also thought about the other source of the PROCSIG_PARALLEL_MESSAGE sign=
al,
a few lines above the call to shm_mq_attach():

	before_shmem_exit(ParallelWorkerShutdown, PointerGetDatum(seg));

If the worker called proc_exit() after this, but before the call of
shm_mq_attach(), the worker handle might be useful for the leader to concl=
ude
that the worker hasn't detached yet. However, the coding of
ProcessParallelMessages() is such that shm_mq_receive() can return
SHM_MQ_WOULD_BLOCK in such a case, so the ERROR "lost connection to parall=
el
worker" is not raised anyway.


While thinking about that ERROR, I realize that I might have misunderstood=
 its
purpose, and therefore it's not present in
ProcessRepackMessage(). Nevertheless, I'm still not sure I understand when
exactly should that ERROR be raised. Per commit 2badb5afb8, the function
ParallelWorkerShutdown() is related. However, AFAICS, when the worker code
calls proc_exit(), the ParallelWorkerShutdown() callback can send the
PROCSIG_PARALLEL_MESSAGE signal while the worker is still attached to the
error queue. In that case, the ERROR is not raised.

I'm probably missing something. Thanks in advance for any hint.

-- =

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