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 1opcho-0004V1-4T for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Oct 2022 21:52:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1opchm-0005Vl-Vz for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Oct 2022 21:52:26 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1opchm-0005Vc-JM for pgsql-hackers@lists.postgresql.org; Mon, 31 Oct 2022 21:52:26 +0000 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1opchk-00059i-3f for pgsql-hackers@lists.postgresql.org; Mon, 31 Oct 2022 21:52:26 +0000 Received: by mail-wm1-x331.google.com with SMTP id r186-20020a1c44c3000000b003cf4d389c41so8921742wma.3 for ; Mon, 31 Oct 2022 14:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=7cyoYWqJouoQW8MU2zP4ercrXBSULMace/W54y3MIBk=; b=UdyHqynrbqE9awOK/0/mhQvFJRfmwHJ75NEj9Z6Ntm9krqiS4k+zsvu6wtPiAxf6ZG N1Y2rcyFGFWLP+U3VS+KKBd3eXXPuD0rmFbN/V4eJW9GbE3eyT4ykhwOMv9hfTqrRGzA +mCDz9fhBNTqqnL2OlDSH4+4mqfUGWXRPHPsBrzJq69al/tzcv5HHwM+ZFveF6WvobIR u5E8w9on0CSPjIKntZh7UYl3iIIBarHRxNm66nukH3oPqKOI3QjWikbvpyXTS2QTp95w bp55VygWY2AzzGMOpeLOwz0qAmbU/3pVOoaFlz2oEikHLmi4v0WEtlYUehtVpklQiWK3 U0Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=7cyoYWqJouoQW8MU2zP4ercrXBSULMace/W54y3MIBk=; b=QxL8zDL6wuuC30WrYAZ2aGOm7lGgfA2phE1TMxQIN6cj6Z5ocp6nDL0JXutqewGen2 b5ZL18EfCmS6WkRUUm3EqP37/mo+uAQEd6IFTOCvP7yB+cdLgCHlrEiiTlcYRrHM7Uw4 t2/NoegLlpvVOopMbk+QAyq22zShwZP875gDCdsiYKoT1OkeNWcGl7mJ25pPgJpVtDXz 1NkAhFfZbPdYBrdEQUgilvZgvlkr4s1+nneROKmHP5FuIoqFeag78p546lDoKqLVUGVG +H85IZ4dfVai1JEHs1jLd1wq5lTu8Vw71iTfkX1+pWvni+rH8Mh6HLygYPTA4yAIxilj cTtw== X-Gm-Message-State: ACrzQf22QlENB+cR233P4Mx12HTEkaUdRVC724NjXgF2JIyq5+6lP/y8 zPYx7Pjq3puOVijlDIcW0pM= X-Google-Smtp-Source: AMsMyM6/fsZIbB3ic1zYlswYccZdwN6S3R4oIQx0JIQEHPdJsGpXXat0auirJwwogRF95cXDEOcvjg== X-Received: by 2002:a05:600c:5408:b0:3cf:7195:4dfb with SMTP id he8-20020a05600c540800b003cf71954dfbmr4698677wmb.189.1667253142097; Mon, 31 Oct 2022 14:52:22 -0700 (PDT) Received: from qoops-lap.home ([46.71.128.10]) by smtp.gmail.com with ESMTPSA id k5-20020a05600c0b4500b003c6c4639ac6sm8359538wmr.34.2022.10.31.14.52.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Oct 2022 14:52:21 -0700 (PDT) Message-ID: <7a2673fad058365b7583fbabcaca61fa3a36d40c.camel@gmail.com> Subject: Re: Segfault on logical replication to partitioned table with foreign children From: Ilya Gladyshev To: Alvaro Herrera Cc: pgsql-hackers@lists.postgresql.org Date: Tue, 01 Nov 2022 01:52:19 +0400 In-Reply-To: <20221030155239.55zehfskzdppokox@alvherre.pgsql> References: <20221030155239.55zehfskzdppokox@alvherre.pgsql> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, 2022-10-30 at 16:52 +0100, Alvaro Herrera wrote: > On 2022-Oct-28, ilya.v.gladyshev@gmail.com wrote: > > > This will cause a segfault or raise an assert, because inserting > > into > > foreign tables via logical replication is not possible. The > > solution I > > propose is to add recursive checks of relkind for children of a > > target, > > if the target is a partitioned table. > > However, I imagine that the only reason we don't support this is that > the code hasn't been written yet. I think it would be better to write > that code, so that we don't have to raise any error at all (unless > the > foreign table is something that doesn't support DML, in which case we > would have to raise an error).  Of course, we still have to fix it in > backbranches, but we can just do it as a targeted check at the moment > of > insert/update, not at the moment of subscription create/alter. > Sure, this patch is just a quick fix. A proper implementation of logical replication into foreign tables would be a much more difficult undertaking. I think this patch is simple enough, the checks in the patch are performed both on subscription DDL and when the relation is opened for logical replication, so it gives both early feedback and last-minute checks as well. All the code infrastructure for these kinds of checks is already in place, so I think it's a good idea to use it. P.S. sorry, duplicating the message, forgot to cc the mailing list the first time