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

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.

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.

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

Best regards,
Hayato Kuroda
FUJITSU LIMITED