Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

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!"