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

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Cc: Alexander Lakhin <exclusion(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation
Date: 2026-11-02 19:44:45
Message-ID: CAD21AoBiLsXeZ-td5ys_sX9_vHt57YoQg8-PzNneMGsTeByQGw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Nov 1, 2026 at 8:47 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Hi Sawada-san,
>
> > I've reviewed only the 0001 patch. While I agree with your analysis,
>
> Thanks!
>
> > I
> > think it's sufficient to call injection_points_detach() before quit,
> > no?
>
> That's not enough. As I posted in the previous post, exiting backend which calls
> _set_local can cleanup injection points registered by other backends.
> Here below scenario can still happen:
>
> 0. assuming that there is a background psql session, and the related backend (b1)
> does _set_local() and _attach() for an injection point "logical-decoding-activation".
> b1 has been storing the name in inj_list_local.
> 1. a backend (b2) calls _detach(). An injection point is removed from the shared hash.
> 2. the background psql session quits, the b1 starts exiting (and delayed).
> 3. another backend (b3) calls _set_local() and _attach() for the same injection
> point "logical-decoding-activation". It's registered on the shared hash.
> 4. b1 reaches the cleanup function and removes "logical-decoding-activation"
> from the shared hash.
> 5. b3 calls pg_create_logical_replication_slot(). Since the injection point has
> already been removed it won't wait anymore.
> 6. upcoming wait_for_event() stucks since nobody waits there
>
> I confirmed that the test could still fail by adding detach() before the quit atop the reproducer.

Agreed.

> Alternative fix idea is to ensure the backend process exits, v2 implements the same.
> If we want to use _detach() approach we need to fix race condition for injection
> ponits side.
>
> > Also, the following codes in 051_effective_wal_level.pl seems to
> > have the same issue;
>
> Right, fixed.

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().

The 0002 patch looks good to me.

I'll review the 0003 patch soon.

Regards,

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message surya poondla 2026-11-02 19:44:50 Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish
Previous Message Joel Jacobson 2026-11-02 19:37:57 Re: PostgreSQL 19 GA press release draft