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 1tkQ3X-003kTD-KY for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Feb 2025 16:02:43 +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 1tkQ3V-00Bm70-Vl for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Feb 2025 16:02:41 +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 1tkQ3V-00Bm6T-Lq for pgsql-hackers@lists.postgresql.org; Tue, 18 Feb 2025 16:02:41 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tkQ3T-001XpI-2g for pgsql-hackers@postgresql.org; Tue, 18 Feb 2025 16:02:40 +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 51IG2cpL1243985; Tue, 18 Feb 2025 11:02:38 -0500 From: Tom Lane To: Robert Haas cc: "David G. Johnston" , Ayush Vatsa , PostgreSQL Hackers Subject: Re: Clarification on Role Access Rights to Table Indexes In-reply-to: References: <855988.1739816850@sss.pgh.pa.us> <861660.1739819589@sss.pgh.pa.us> <908583.1739822263@sss.pgh.pa.us> <934709.1739829723@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 18 Feb 2025 10:13:03 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <1243983.1739894558.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Feb 2025 11:02:38 -0500 Message-ID: <1243984.1739894558@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Mon, Feb 17, 2025 at 5:18=E2=80=AFPM David G. Johnston > wrote: >>> I have a very vague recollection that we concluded that SELECT >>> privilege was a reasonable check because if you have that you >>> could manually prewarm by reading the table. That would lead >>> to the conclusion that the minimal fix is to look at the owning >>> table's privileges instead of the index's own privileges. >> I feel like if you can blow up the cache by loading an entire table int= o memory with just select privilege on the table we should be ok with allo= wing the same person to name an index on the same table and load it into t= he cache too. > +1. Is that a +1 for the specific design of "check SELECT on the index's table", or just a +1 for changing something here? regards, tom lane