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 1tk5RU-00HQme-J9 for pgsql-general@arkaria.postgresql.org; Mon, 17 Feb 2025 18:02:04 +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 1tk5RS-0012KQ-W3 for pgsql-general@arkaria.postgresql.org; Mon, 17 Feb 2025 18:02:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tk5RS-0012KI-L9 for pgsql-general@lists.postgresql.org; Mon, 17 Feb 2025 18:02:02 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1tk5RQ-001OdG-05 for pgsql-general@lists.postgresql.org; Mon, 17 Feb 2025 18:02:02 +0000 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5dea50ee572so7006285a12.1 for ; Mon, 17 Feb 2025 10:01:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739815318; x=1740420118; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=QweJXEVz0MCEU2gusMSRvNkdJeESUnE48xFmWE0HKJc=; b=Nc4RstcMsj+WLcGSpL0/Ulm/Im7449HewbeqyELhJ6KEVmdZPfuyhkIyqdW6O9TZAX dhI6gxxMfjvXRlDKAC4p7TzygnQNQkIn3TuoCUfu47gVUBmyfdZrzbAm3VR1ootjtaRS T6VRtW0IlyDmeuzROJbbVAjDUb+6aDJZqgh82fbyVZC8EL9MwwNSpz8GBSO8tNiWeZxc hIbNYwif1S+V7TVvFoFUanDgZoPXgYa4FzMlKj/UAV0rWAaXOGui6odsB1fP9+pYuRan cnBG5norTcEtNUcPMiwmlULsXQhJSK5SuhamdmvYab23Jf7VJNLJBvyXl3QtT9qs0jL+ sWHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739815318; x=1740420118; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QweJXEVz0MCEU2gusMSRvNkdJeESUnE48xFmWE0HKJc=; b=a/C3U4zcfHr3kEXgi2DlGP3rCEtSM9aBguyFd/hw4uiTfjOprx3OW2JTJ3rljMRVB+ jsga0wSRy6qdFIbeGlW7eUsCEih+y6a/GAlzJsJQi48D7OB8A3SARbz02A6VSbuewYiY DYGYOeBPDPSk+kui4ViyMpsyVtCvC18PQ4V6jvyt4l12lJhR9OpB0ZmnzH2QgHHGHCVi 5nXuhmOptj/Rd/61S6Zmos9Il+Hbk6GvTkrbxjLTuSOYn10Sxm1LFoSNFL/SwcHipBbp ykl6lN4rTyPnsoRDTr3E/CFXi24BX+ng8fyG4BlUfIB8vbz7ljVWk/7LSvjx7/TZXzqR FpLw== X-Gm-Message-State: AOJu0Yz7ojQ5GN6jxbwEPtzIcdS687Xxfno3ikPC3f12Xs+yKHgW0s01 zB7GbqtTHYOuBcwmyxfdI4PsSXa3/nmqF4/KEgGrHKDKYmOcWRCq0opPvYNuVAse0MUfqGCzrzV 1WM7jErZt5I10tyPIWc0ZlKv7g1mzTiaF X-Gm-Gg: ASbGnctRti++A9BRQdtFakIilEagVZnSkTsA+GY88Af90fFtNbXqZ5zMUvKr7ca6nl8 RZTbSPATPTN0uZzQn+/DcVKrDp2NKmbi1bBdyCEmoQVlsIwIBFRjBLZXZFVBDvX0tCZ6t+Q== X-Google-Smtp-Source: AGHT+IGsPNQw5v1NbYVRnEYvgn+eUWYp8qyCnVztyBZNFoehPRZLp8RhdoKLMfiP7Ep3TyE5BnkHJ0fbzZO7sslPOyk= X-Received: by 2002:a05:6402:254a:b0:5de:d803:31f3 with SMTP id 4fb4d7f45d1cf-5e036174858mr7799995a12.21.1739815318044; Mon, 17 Feb 2025 10:01:58 -0800 (PST) MIME-Version: 1.0 From: Ayush Vatsa Date: Mon, 17 Feb 2025 23:31:46 +0530 X-Gm-Features: AWEUYZkbFcMwz5IDnKjzV0L9loFsgAxLoJOm1qae_OPjBvqysVlAvK0yPfg6P3E Message-ID: Subject: Clarification on Role Access Rights to Table Indexes To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000001c509062e5a5247" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000001c509062e5a5247 Content-Type: text/plain; charset="UTF-8" Hi PostgreSQL Community, I am currently exploring the behavior of pg_prewarm and encountered an issue related to role access rights that I was hoping you could help clarify. Here is the scenario I observed: postgres=# CREATE ROLE alpha; CREATE ROLE postgres=# GRANT SELECT ON pg_class TO alpha; GRANT postgres=# SET ROLE alpha; SET postgres=> SELECT pg_prewarm('pg_class'); pg_prewarm ------------ 14 (1 row) postgres=> SELECT pg_prewarm('pg_class_oid_index'); ERROR: permission denied for index pg_class_oid_index postgres=> RESET ROLE; RESET postgres=# GRANT SELECT ON pg_class_oid_index TO alpha; ERROR: "pg_class_oid_index" is an index Based on this, I have few questions: 1. Can a role have access rights to a table without having access to its index? 2. If yes, how can we explicitly grant access to the index? 3. If no, and the role inherently gets access to the index when granted access to the table, why does the pg_prewarm call fail [1] in the above scenario? [1] https://github.com/postgres/postgres/blob/master/contrib/pg_prewarm/pg_prewarm.c#L108-L110 Regards, Ayush Vatsa SDE AWS --00000000000001c509062e5a5247 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi PostgreSQL Community,
I am currently exploring th= e behavior of pg_prewarm and encountered an issue related to r= ole
access rights that I was hoping you could help clarify.

Here i= s the scenario I observed:

postgres=3D# CREATE ROLE alpha;
CREATE = ROLE
postgres=3D# GRANT SELECT ON pg_class TO alpha;
GRANT
postgre= s=3D# SET ROLE alpha;
SET
postgres=3D> SELECT pg_prewarm('pg_c= lass');
=C2=A0pg_prewarm
------------
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A014
(1 row)

postgres=3D> SELECT pg_prewarm('pg= _class_oid_index');
ERROR: =C2=A0permission denied for index pg_clas= s_oid_index
postgres=3D> RESET ROLE;
RESET

postgres=3D# GRA= NT SELECT ON pg_class_oid_index TO alpha;
ERROR: =C2=A0"pg_class_oi= d_index" is an index

Based on this, I have=C2=A0few questions:1. Can a role have access rights to a table without having access to its = index?
2. If yes, how can we explicitly grant access to the index?
3.= If no, and the role inherently gets access to the index when granted acces= s to the table, why
does the pg_prewarm call fail [1] in th= e above scenario?

[1]=C2=A0https://githu= b.com/postgres/postgres/blob/master/contrib/pg_prewarm/pg_prewarm.c#L108-L1= 10


Regards,
Ayush Vatsa
SDE AWS

--00000000000001c509062e5a5247--