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 1ot6CC-0003cq-31 for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Nov 2022 11:58:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ot6CA-0003Uq-Ly for pgsql-hackers@arkaria.postgresql.org; Thu, 10 Nov 2022 11:58:10 +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 1ot6CA-0003Tv-CK for pgsql-hackers@lists.postgresql.org; Thu, 10 Nov 2022 11:58:10 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ot6C7-0001QD-PS for pgsql-hackers@lists.postgresql.org; Thu, 10 Nov 2022 11:58:09 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C57325C0110; Thu, 10 Nov 2022 06:58:04 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 10 Nov 2022 06:58:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1668081484; x=1668167884; bh=I kGgIVf1UI5o3DQ1Swrn7D2dQmXLMRfA3ulLvtvVQ3c=; b=tpbXRnB+KTmw1oiJ1 5m0kBpTluCk7mO8D4NgdJozBlkcIBOMFborw3f1ICzHfh4sbg/ghowGur0nAzpW5 M8KPiNk4ioImkjkYI0U9JBGhDAQzlv8vexr66NB0WDa+bfGLFywlGbClVeHnnsyi 2d2Yt84QPBBc9WMOAIbMlwVDLPpDhe5FwQCVRpVevHPj25JFXxgQRabru77kODc/ BPrpZyNb2KosnzCVSaBoIInExDVwZMYgrhJjAKWm8cQMbIvmTjES5RW2+rUqn67T 1UM7ir7SkP1rBQ5TYqWTpQQmVoP5hPlXuSHSAGYhfcmDER4BepiP/vrrjmMDdHSg HjFNQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeeggdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfggtggugfgjsehmkeerredttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeduleekkefgtddttedtkefguddvieffleetgeejiefhteeh keevfeettdduvdfhueenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghlvhhh vghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Nov 2022 06:58:04 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 9EFDF39B; Thu, 10 Nov 2022 12:58:01 +0100 (CET) Date: Thu, 10 Nov 2022 12:58:01 +0100 From: Alvaro Herrera To: Amit Langote Cc: Ian Lawrence Barwick , Tom Lane , David Rowley , Greg Stark , Zhihong Yu , Julien Rouhaud , PostgreSQL Hackers Subject: Re: ExecRTCheckPerms() and many prunable partitions Message-ID: <20221110115801.qnsaci3viwlcpy42@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="oza3eh5eyt5u5bwx" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --oza3eh5eyt5u5bwx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello I've been trying to understand what 0001 does. One thing that strikes me is that it seems like it'd be easy to have bugs because of modifying the perminfo list inadequately. I couldn't find any cross-check that some perminfo element that we obtain for a rte does actually match the relation we wanted to check. Maybe we could add a test in some central place that perminfo->relid equals rte->relid? A related point is that concatenating lists doesn't seem to worry about not processing one element multiple times and ending up with bogus offsets. (I suppose you still have to let an element be processed multiple times in case you have nested subqueries? I wonder how good is the test coverage for such scenarios.) Why do callers of add_rte_to_flat_rtable() have to modify the rte's perminfoindex themselves, instead of having the function do it for them? That looks strange. But also it's odd that flatten_unplanned_rtes concatenates the two lists after all the perminfoindexes have been modified, rather than doing both things (adding each RTEs perminfo to the global list and offsetting the index) as we walk the list, in flatten_rtes_walker. It looks like these two actions are disconnected from one another, but unless I misunderstand, in reality the opposite is true. I think the API of ConcatRTEPermissionInfoLists is a bit weird. Why not have the function return the resulting list instead, just like list_append? It is more verbose, but it seems easier to grok. Two trivial changes attached. (Maybe 0002 is not correct, if you're also trying to reference finalrtepermlist; but in that case I think the original may have been misleading as well.) -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ --oza3eh5eyt5u5bwx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0002-Simplify-comment-a-little-bit.patch.txt" From 47afb0d3e1cf6fdf77b5ace643ece15e9c618006 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Thu, 10 Nov 2022 12:34:01 +0100 Subject: [PATCH 2/2] Simplify comment a little bit --- src/include/nodes/parsenodes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h index 39e9e82bfc..abcf8ee229 100644 --- a/src/include/nodes/parsenodes.h +++ b/src/include/nodes/parsenodes.h @@ -1026,7 +1026,7 @@ typedef struct RangeTblEntry * avoid getting an additional, lesser lock. * * perminfoindex is 1-based index of the RTEPermissionInfo belonging to - * this RTE in the query's list of RTEPermissionInfos; 0 if permissions + * this RTE in the containing query's rtepermlist; 0 if permissions * need not be checked for the RTE. */ Oid relid; /* OID of the relation */ -- 2.30.2 --oza3eh5eyt5u5bwx Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="0001-fix-typo.patch.txt" From 682313f8cd4402b4049792e001b4c24ff691a8f1 Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Thu, 10 Nov 2022 12:33:44 +0100 Subject: [PATCH 1/2] fix typo --- src/include/nodes/parsenodes.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h index 2d648a8fdd..39e9e82bfc 100644 --- a/src/include/nodes/parsenodes.h +++ b/src/include/nodes/parsenodes.h @@ -1187,7 +1187,7 @@ typedef struct RangeTblEntry * reference is represented by setting the bit for InvalidAttrNumber. * * updatedCols is also used in some other places, for example, to determine - * which triggers to fire and in FDWs to know which changed columns the need + * which triggers to fire and in FDWs to know which changed columns they need * to ship off. * * Generated columns that are caused to be updated by an update to a base -- 2.30.2 --oza3eh5eyt5u5bwx--