| 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
| 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 |