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 1oqGkU-0002wx-LQ for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Nov 2022 16:37:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oqGkT-00049Z-GB for pgsql-hackers@arkaria.postgresql.org; Wed, 02 Nov 2022 16:37:53 +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 1oqGkT-00049Q-6u for pgsql-hackers@lists.postgresql.org; Wed, 02 Nov 2022 16:37:53 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oqGkM-000555-Ns for pgsql-hackers@lists.postgresql.org; Wed, 02 Nov 2022 16:37:52 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2A2Gbg2d1787919; Wed, 2 Nov 2022 12:37:42 -0400 From: Tom Lane To: Ilya Gladyshev cc: "shiy.fnst@fujitsu.com" , Dilip Kumar , "pgsql-hackers@lists.postgresql.org" Subject: Re: Segfault on logical replication to partitioned table with foreign children In-reply-to: <1361869.1667329814@sss.pgh.pa.us> References: <6b93e3748ba43298694f376ca8797279d7945e29.camel@gmail.com> <188734.1667137161@sss.pgh.pa.us> <04b5212cd549ee3c8efc63f6a92d85d5463bfdf1.camel@gmail.com> <1361869.1667329814@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Tue, 01 Nov 2022 15:10:14 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1787917.1667407062.1@sss.pgh.pa.us> Date: Wed, 02 Nov 2022 12:37:42 -0400 Message-ID: <1787918.1667407062@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Since we're getting pretty close to the next set of back-branch releases, I went ahead and pushed a minimal fix along the lines suggested by Shi Yu. (I realized that there's a second ExecFindPartition call in worker.c that also needs a check.) We still can at leisure think about refactoring CheckSubscriptionRelkind to avoid unnecessary lookups. I think that is something we should do only in HEAD; it'll just be a marginal savings, not worth the risks of API changes in stable branches. The other loose end is whether to worry about a regression test case. I'm inclined not to bother. The only thing that isn't getting exercised is the actual ereport, which probably isn't in great need of routine testing. regards, tom lane