Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQpIS-0016Hc-4V for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Aug 2023 13:20:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1qQpIQ-006UJ1-08 for pgsql-hackers@arkaria.postgresql.org; Tue, 01 Aug 2023 13:20:19 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQpIP-006UIt-NI for pgsql-hackers@lists.postgresql.org; Tue, 01 Aug 2023 13:20:19 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qQpIO-000BP1-GA for pgsql-hackers@postgresql.org; Tue, 01 Aug 2023 13:20:17 +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 371DKELL3070527; Tue, 1 Aug 2023 09:20:14 -0400 From: Tom Lane To: Richard Guo cc: PostgreSQL-development Subject: Re: Oversight in reparameterize_path_by_child leading to executor crash In-reply-to: References: Comments: In-reply-to Richard Guo message dated "Tue, 01 Aug 2023 16:44:27 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3070525.1690896014.1@sss.pgh.pa.us> Date: Tue, 01 Aug 2023 09:20:14 -0400 Message-ID: <3070526.1690896014@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > In this case what we need to do is to adjust the TableSampleClause to > refer to the correct child relations. We can do that with the help of > adjust_appendrel_attrs_multilevel(). One problem is that the > TableSampleClause is stored in RangeTblEntry, and it does not seem like > a good practice to alter RangeTblEntry in this place. Ugh. That's why we didn't think to adjust it, obviously. You are right that we can't just modify the RTE on the fly, since it's shared with other non-parameterized paths. > So what I'm thinking is that maybe we can add a new type of path, named > SampleScanPath, to have the TableSampleClause per path. Then we can > safely reparameterize the TableSampleClause as needed for each > SampleScanPath. That's what the attached patch does. Alternatively, could we postpone the reparameterization until createplan.c? Having to build reparameterized expressions we might not use seems expensive, and it would also contribute to the memory bloat being complained of in nearby threads. > There are some other plan types that do not have a separate path type > but may have lateral references in expressions stored in RangeTblEntry, > such as FunctionScan, TableFuncScan and ValuesScan. But it's not clear > to me if there are such problems with them too. Hmm, well, not for partition-wise join anyway. regards, tom lane