Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzWJy-0002JJ-A2 for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Dec 2021 04:00:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mzWJw-0002IV-8s for pgsql-bugs@arkaria.postgresql.org; Tue, 21 Dec 2021 04:00:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mzWJv-0002IM-PP for pgsql-bugs@lists.postgresql.org; Tue, 21 Dec 2021 04:00:11 +0000 Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mzWJo-00014N-Vv for pgsql-bugs@lists.postgresql.org; Tue, 21 Dec 2021 04:00:10 +0000 Received: by mail-lj1-x22c.google.com with SMTP id 13so19152855ljj.11 for ; Mon, 20 Dec 2021 20:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=wve0TqW9jeehjXz3034qs6bJFRIIp5qhGP9vVjyuU7Y=; b=kIlDPHn9rcHtjf/PCr2kkfBGB4SBlwTdeX69CBux3RkT4Opq+FGBA4glPY5TQqc4Ob ICzNdA7fe1rIq/uDgroHAUYtXlZL8DLs3EHcIYry16Kgnz/EY8hcivNglDpClY2V01Ah 47ePCMsS/X6U8EKKqF2BsTr0xAleQPoFQEW5maFG/qRVK4WV4NcFDWwkqpI1dKIaazni d191YCUUmIEBLZf7ohf+zcYJHT5y+aZJbxbtGh31rDgHgIvMopzH0PQ1nMivQFEJ9Zgd UmPc3FnPAQkAqNNoO+HwA8KXXWeM9EB4/g2gtNPyUwJGr9/wEV9TxWrRmQsbRNG1zl82 jGWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=wve0TqW9jeehjXz3034qs6bJFRIIp5qhGP9vVjyuU7Y=; b=vM+wvND/5nd+8+MDgkDMtOFrrczByfsGXwP1ocVACGzWBJR/Qg2SHiRXjXC4zd7r09 YHUmp+NrAMb9EcDfK4fky7QISgfI5mN+Ci2Uz3eutoYZEj18xYoK6UozA4OocTttPpP/ dedHde8lUgjhxjIUqQYnGGw+GqC7HT0aj423C+LoYv1n38KR7Ucic8ZB4MDSpl9L66Ql 5wMPS3j6XHgIkXgSh9zq9KZNupPBqncTDL4Kz/7W0lQXQaTbZRCzwV8dOJSamQD0vbZ5 7W2KdEk3EF9nQHkJsRWNJcwlTx3o/zcoDAsZkChtL+zE0n+ToKqc60E55cIyLyGJ3bT7 kF/w== X-Gm-Message-State: AOAM532jiMWHe0DusPNgu/F2+izQRk0jL2ItjCP5G3oTj0ox8TsmMuac Lbzt8AJ5NNQlHoqBoN1I1Aj3rNK0YkqnsQ== X-Google-Smtp-Source: ABdhPJzjvTSMEdQ6nx8OIsutf9Lwdlh7LBsZi/h2FEtRPc5OzXGJM+xboT5vOf2cFptE3sXB/Eruhw== X-Received: by 2002:a2e:b171:: with SMTP id a17mr1022280ljm.56.1640059202674; Mon, 20 Dec 2021 20:00:02 -0800 (PST) Received: from [1.0.0.7] ([178.155.6.232]) by smtp.gmail.com with ESMTPSA id c3sm7111ljr.24.2021.12.20.20.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Dec 2021 20:00:02 -0800 (PST) Subject: Re: BUG #17339: Assert failed on attempt to detach a sequence concurrently To: Kyotaro Horiguchi , michael@paquier.xyz Cc: peter.eisentraut@enterprisedb.com, pgsql-bugs@lists.postgresql.org References: <20211221.120322.916207154734438884.horikyota.ntt@gmail.com> From: Alexander Lakhin Message-ID: <91a6d779-126b-734c-5f73-e9282a3405a5@gmail.com> Date: Tue, 21 Dec 2021 07:00:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20211221.120322.916207154734438884.horikyota.ntt@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello Michael and Kyotaro-san, 21.12.2021 06:03, Kyotaro Horiguchi wrote: >> This would also fail when attempting to detach a foreign table, as >> well, and these are legal relkinds in a partition tree. Once we do >> that, we fall down into the same failure as for the non-concurrent >> mode in RemoveInheritance(), telling that the relation is not a member >> of the partition tree. > I agree to the discussion above thus it seems to me right that we just > remove the assertion. We never have a partition of un-attachable > relkind so such kind of relations are surely rejected just after. The > assertion on "== RELKIND_PARTITIONED_TABLE" is still valid since we > don't reach there for the case of the traditional inheritance. > > As detaching a foreign table is a valid scenario (not covered before), maybe it's worth to exercise it as following: --- a/contrib/postgres_fdw/sql/postgres_fdw.sql +++ b/contrib/postgres_fdw/sql/postgres_fdw.sql @@ -1490,6 +1490,8 @@ CREATE FOREIGN TABLE foreign_tbl (a int, b int)    CREATE TABLE parent_tbl (a int, b int) PARTITION BY RANGE(a);  ALTER TABLE parent_tbl ATTACH PARTITION foreign_tbl FOR VALUES FROM (0) TO (100); +ALTER TABLE parent_tbl DETACH PARTITION foreign_tbl CONCURRENTLY; +ALTER TABLE parent_tbl ATTACH PARTITION foreign_tbl FOR VALUES FROM (0) TO (100);    CREATE VIEW rw_view AS SELECT * FROM parent_tbl    WHERE a < b WITH CHECK OPTION; Thanks! Best regards, Alexander