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

From: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
To: 'Masahiko Sawada' <sawada(dot)mshk(at)gmail(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-11 01:53:27
Message-ID: OS7PR01MB18317BFFDEE499F51C8963826F5712@OS7PR01MB18317.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Sawada-san,

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

Great, thanks!

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

Exactly.

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

Right, otherwise, how can the stopped process resume working?

> 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 also mentioned the possibility in [1] but I have not tried yet. +1 it's the
proper approach.

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

Sure, I would fork a new thread after implementing both approaches.
Will include you and Alexander in CC. Let’s close this thread.

[1]: https://www.postgresql.org/message-id/OS7PR01MB183172A425382C8A781DB153FF56D2%40OS7PR01MB18317.jpnprd01.prod.outlook.com

Best regards,
Hayato Kuroda
FUJITSU LIMITED

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-11-11 01:55:52 pg_basebackup: check timeline history file write failures in ReceiveXlogStream()
Previous Message Michael Paquier 2026-11-11 01:42:01 Re: [PG19] pg_dump marks extended statistics of pre-v15 partitioned tables as non-inherited