On 2021-Mar-19, Alvaro Herrera wrote: > diff --git a/src/backend/utils/cache/partcache.c > b/src/backend/utils/cache/partcache.c > index 0fe4f55b04..6dfa3fb4a8 100644 > --- a/src/backend/utils/cache/partcache.c > +++ b/src/backend/utils/cache/partcache.c > @@ -352,16 +352,9 @@ generate_partition_qual(Relation rel) > return copyObject(rel->rd_partcheck); > > /* > - * Obtain parent relid; if it's invalid, then the partition is being > - * detached. The constraint is NIL in that case, and let's cache that. > + * Obtain parent relid. XXX explain why we need this > */ > - parentrelid = get_partition_parent(RelationGetRelid(rel)); > - if (parentrelid == InvalidOid) > - { > - rel->rd_partcheckvalid = true; > - rel->rd_partcheck = NIL; > - return NIL; > - } > + parentrelid = get_partition_parent(RelationGetRelid(rel), true);
One thing that makes me uneasy about this, is that I don't understand how does this happen with your test of two psqls doing attach/detach. (It is necessary for the case when the waiting concurrent detach is canceled, and so this fix is necessary anyway). In your test, no waiting transaction is ever cancelled; so what is the period during which the relation is not locked that causes this code to be hit? I fear that there's a bug in the lock protocol somewhere. -- Álvaro Herrera Valdivia, Chile "In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth. That's because in Europe they call me by name, and in the US by value!"