On Sun, Apr 11, 2021 at 05:20:35PM -0400, Alvaro Herrera wrote: > On 2021-Mar-31, Tom Lane wrote: > > > diff -U3 > > /home/buildfarm/trilobite/buildroot/HEAD/pgsql.build/src/test/isolation/expected/detach-partition-concurrently-4.out > > > > /home/buildfarm/trilobite/buildroot/HEAD/pgsql.build/src/test/isolation/output_iso/results/detach-partition-concurrently-4.out > > --- > > /home/buildfarm/trilobite/buildroot/HEAD/pgsql.build/src/test/isolation/expected/detach-partition-concurrently-4.out > > 2021-03-29 20:14:21.258199311 +0200 > > +++ > > /home/buildfarm/trilobite/buildroot/HEAD/pgsql.build/src/test/isolation/output_iso/results/detach-partition-concurrently-4.out > > 2021-03-30 18:54:34.272839428 +0200 > > @@ -324,6 +324,7 @@ > > 1 > > 2 > > step s1insert: insert into d4_fk values (1); > > +ERROR: insert or update on table "d4_fk" violates foreign key constraint > > "d4_fk_a_fkey" > > step s1c: commit; > > > > starting permutation: s2snitch s1b s1s s2detach s1cancel s3vacfreeze s1s > > s1insert s1c > > Hmm, actually, looking at this closely, I think the expected output is > bogus and trilobite is doing the right thing by throwing this error > here. The real question is why isn't this case behaving in that way in > every *other* animal.
I was looking/thinking at it, and wondered whether it could be a race condition involving pg_cancel_backend() -- Justin
