On Mon, Apr 12, 2021 at 6:23 AM Justin Pryzby <pry...@telsasoft.com> wrote: > 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()
I thought about it some and couldn't come up with an explanation as to why pg_cancel_backend() race might be a problem. Actually it occurred to me this morning that CLOBBER_CACHE_ALWAYS is what exposed this problem on this animal (not sure if other such animals did too though). With CLOBBER_CACHE_ALWAYS, a PartitionDesc will be built afresh on most uses. In this particular case, the RI query executed by the insert has to build a new one (for d4_primary), correctly excluding the detach-pending partition (d4_primary1) per the snapshot with which it is run. In normal builds, it would reuse the one built by an earlier query in the transaction, which does include the detach-pending partition, thus allowing the insert trying to insert a row referencing that partition to succeed. There is a provision in RelationGetPartitionDesc() to rebuild if any detach-pending partitions in the existing copy of PartitionDesc are not to be seen by the current query, but a bug mentioned in my earlier reply prevents that from kicking in. -- Amit Langote EDB: http://www.enterprisedb.com
