Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation

On Mon, Nov 2, 2026 at 8:20 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Hi Sawada-san,
>
> > The 0001 patch basically looks good to me. Is there any reason that
> > the patch sets "verbose => 0" to some query_safe() calls? Also, I'd
> > suggest renaming the support function to quit_and_wait().
>
> I just tried to suppress output, not mandatory. PSA fixed version.
> I fixed 0001 as well.

Thank you for updating the patch! I pushed 0001 and 0002.

> > I'll review the 0003 patch soon.

IIUC the problem that the 0003 patch tries to fix is somewhat
different from the problem that the 0001 patch fixed. The former is
that a backend's exit cleanup can detach an injection point that is
attached by another backend, whereas the latter is that attaching an
injection point can fail with "already defined" error if the backend
behind a background psql session is slow to exit for some reason.

Regarding the former issue, I think it's okay that an injection point
is detached by someone other than the one who attached it, since
injection_points_detach() takes the name of the point and injection
point names are global across backends. The problem is that injection
points are also detached at process exit cleanup time, and it could
detach the point even if it was attached by someone else. So if
another backend attaches the same injection point in between, the
exiting process blindly detaches it even though it didn't attach that
point. In tests with injection points, it's conventional to do
injection_points_detach() and injection_points_wakeup(), and continue
the next test. I think it would not be great for us to have to take
care of this race condition every time we write a test. I guess it
would be better to fix the injection point side so that detaching
points during process exit cleanup affects only the points attached by
itself.

I think it's already a separate topic from the issue reported in this
thread, so I'd suggest starting a new thread for this problem. We can
decide whether we need the 0003 patch based on the discussion there.
Fortunately, the problem in 010_index_concurrently_upsert.pl hasn't
happened on buildfarm yet, so we would have some time to discuss the
right approach for this issue.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com