Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

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