Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

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.

--
Álvaro Herrera Valdivia, Chile
"Puedes vivir sólo una vez, pero si lo haces bien, una vez es suficiente"