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