merge-delete isolation test fails since 85f55534e80
Hi,
The merge-delete isolation test fails on master for me. It is not
intermittent -- 5 runs out of 5 -- and the failing permutations are all
the WHEN NOT MATCHED BY SOURCE ones.
master @ 89829354de1
Ubuntu 26.04.1 LTS, x86_64, gcc 15.2.0
meson 1.10.1, --buildtype=debug -Dcassert=true -Dtap_tests=enabled
-Dreadline=disabled
Bisected to 85f55534e80 ("Fix concurrent delete handling in MERGE ...
WHEN NOT MATCHED BY SOURCE"):
9bfdcfbfcf9 (parent) 3 of 3 runs pass
85f55534e80 3 of 3 runs fail
89829354de1 (master) 5 of 5 runs fail
That commit added both the fix and these permutations, so what is
failing is the test the commit shipped with.
The row inserted by the WNMBS action looks like it has lost its values.
On the plain table:
step merge_wnmbs_src2: <... completed>
-merge_action|key|val
-INSERT | 2|merge2
+ERROR: null value in column "key" of relation "target" violates
not-null constrainton the partitioned one:
+ERROR: no partition of relation "target_pa" found for row
and the trigger variant prints the row, which is empty:
-s2: NOTICE: Insert: (2,merge2_tg)
+s2: NOTICE: Insert: (,)Five permutations fail, all of them a delete followed by a WNMBS merge:
delete_pa merge_wnmbs_src2_pa c1 select2_pa c2
delete_tg merge_wnmbs_src2_tg c1 select2_tg c2
update delete merge_wnmbs_src2 c1 select2 c2
update_pa delete_pa merge_wnmbs_src2_pa c1 select2_pa c2
update_tg delete_tg merge_wnmbs_src2_tg c1 select2_tg c2
I have only tested master. The commit is marked backpatch-through 17,
so REL_17/18/19 may be affected as well, but I have not checked them.
Happy to test a patch, or to send the full regression.diffs if that is
useful.
Regards,
Trakshan Mishra
Trakshan Mishra <trakshanmishra477@gmail.com> writes:
The merge-delete isolation test fails on master for me. It is not
intermittent -- 5 runs out of 5 -- and the failing permutations are all
the WHEN NOT MATCHED BY SOURCE ones.
The buildfarm is happy with that, so what about your installation is
different from everybody else?
regards, tom lane
Hi Tom,
You are right, and the fault is entirely mine. Sorry for the noise.
What was different about my installation: a stale tmp_install. The
postgres binary the isolation tests were actually executing was dated
20 September, four days old, while the expected files were being read
from a current checkout. So the server predates 85f55534e80 and does
not contain the fix, but the expected output already contained the new
WHEN NOT MATCHED BY SOURCE permutations that commit added.
What I reported as a regression is therefore the original bug that
commit fixes, not a new one. The all-NULL insert is precisely the
behaviour it corrects. I should have caught that from the symptom
alone.
A from-scratch build directory, same tree, same machine, same
configure options:
build (stale tmp_install, binary dated Sep 20) merge-delete fails
build-clean (fresh meson setup, same commit) 133/133 pass
So there is nothing wrong with the commit, and the buildfarm is right.
Apologies to Dean and Tender for the false alarm.
Regards,
Trakshan Mishra
On Thu, Sep 24, 2026 09:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Trakshan Mishra <trakshanmishra477@gmail.com> writes:
The merge-delete isolation test fails on master for me. It is not
intermittent -- 5 runs out of 5 -- and the failing permutations are all
the WHEN NOT MATCHED BY SOURCE ones.The buildfarm is happy with that, so what about your installation is
different from everybody else?regards, tom lane