false failure of test_docoding regression test
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t45629psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 06, 2026 at 11:53 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t45629_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t45629_1 && git checkout t45629_1Patchset v1 (message #1) is on t45629_1
Hello.
The CF-CI complained on one of my patch for seemingly a reason
unrelated to the patch.
https://cirrus-ci.com/task/5544213843542016?logs=test_world#L1666
diff -U3 /tmp/cirrus-ci-build/contrib/test_decoding/expected/slot_creation_error.out /tmp/cirrus-ci-build/contrib/test_decoding/output_iso/results/slot_creation_error.out --- /tmp/cirrus-ci-build/contrib/test_decoding/expected/slot_creation_error.out 2022-03-03 22:45:04.708072000 +0000 +++ /tmp/cirrus-ci-build/contrib/test_decoding/output_iso/results/slot_creation_error.out 2022-03-03 22:54:49.621351000 +0000 @@ -96,13 +96,13 @@ t (1 row)+step s1_c: COMMIT;
step s2_init: <... completed>
FATAL: terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.-step s1_c: COMMIT;
step s1_view_slot:
SELECT slot_name, slot_type, active FROM pg_replication_slots WHERE slot_name = 'slot_creation_error'
This comes from the permuattion 'permutation s1_b s1_xid s2_init
s1_terminate_s2 s1_c s1_view_slot'. That means the process
termination by s1_terminate_s2 is a bit delayed until the next s1_c
ends. So it is rare false failure but it is annoying enough on the
CI. It seems to me we need to wait for process termination at the
time. postgres_fdw does that in regression test.
Thoughts?
Simliar use is found in temp-schema-cleanup. There's another possible
instability between s2_advisory and s2_check_schema but this change
alone reduces the chance for false failures.
The attached fixes the both points.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center