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

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: 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-10-30 08:00:00
Message-ID: 8ccd0497-c914-47e2-804d-299b678863bf@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Sawada-san,

31.07.2026 06:49, Masahiko Sawada wrote:
> What does the buildfarm member produce the above logs? Many buildfarm
> members failed with that error due to commit 6a80179f6b0, but I've not
> seen further failures since pushing commit 18f9785e0b3.

It took 3 months for buildfarm animals to discover an instability of the
fixed test:
[03:38:56.925](0.036s) # injection_point 'logical-decoding-activation' is reached
[03:38:56.997](0.072s) ok 37 - the activation process aborted
[03:38:57.013](0.016s) # connect output:
# {
#   'stderr' => 'background_psql: ready
# ',
#   'stdout' => 'background_psql: ready
# '
# }
[03:42:33.612](216.599s) # poll_query_until timed out executing this query:
#
#         SELECT count(*) > 0 FROM pg_stat_activity
#         WHERE backend_type = 'client backend' AND wait_event = 'logical-decoding-activation'
#
# expecting this output:
# t
# last actual query output:
# f
# with stderr:
[03:42:33.613](0.000s) # die: timed out when waiting for client backend to reach wait event
'logical-decoding-activation' at /home/bf/bf-build/melonworm/HEAD/pgsql/src/test/recovery/t/051_effective_wal_level.pl
line 515.
[03:42:33.613](0.000s) 1..37
timed out when waiting for client backend to reach wait event 'logical-decoding-activation' at
/home/bf/bf-build/melonworm/HEAD/pgsql/src/test/recovery/t/051_effective_wal_level.pl line 515.

I can reproduce this reliably with a simple sleep:
@@ -180,6 +180,7 @@ injection_points_cleanup(int code, Datum arg)
        if (!injection_point_local)
                return;

+pg_usleep(1000000);
        /* Detach all the local points */
        foreach(lc, inj_list_local)
        {

Could you please have a look?

`check-world` with this sleep reveals also other tests suffering from the
same disease:
src/test/modules/test_misc/t/010_index_concurrently_upsert.pl
repack_toast
repack_missingval
repack_temporal
repack_temporal_multirange

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=melonworm&dt=2026-10-30%2002%3A36%3A29

Best regards,
Alexander

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2026-10-30 08:33:49 Re: Return pg_control from pg_backup_stop().
Previous Message Jan Bjørge Løvland 2026-10-30 07:53:24 Re: Design proposal: grain, exact per-time-bucket aggregates from a summarizing index