From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nathan Bossart <nathandbossart@gmail.com>
cc: Ayush Vatsa <ayushvatsa1810@gmail.com>,
        Robert Haas <robertmhaas@gmail.com>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Clarification on Role Access Rights to Table Indexes
In-reply-to: <Z8y9RTT-vU6oVI_Y@nathan>
References: <CA+TgmoZG71zBpLOfCGZqGhtp=88z6=YYhi54TEsCtKr3v+UpoA@mail.gmail.com> <1243984.1739894558@sss.pgh.pa.us> <CA+Tgmob_W0iq9Kuugra3WYTO2429RMJ_+HkVukrXWOUN81QiEw@mail.gmail.com> <1246906.1739896202@sss.pgh.pa.us> <CA+TgmoZYM2az+yCWu5DBnV50N_BE9f1r8-Doy6-tZTySeb-s+A@mail.gmail.com> <CACX+KaNAbOzePn710EtzH9F5xiUdBC+u59=UMab=Wr8jgDKQtw@mail.gmail.com> <Z8dcGMMP3-D5dobY@nathan> <CACX+KaO4R9QDxbPSxSB0jNXFsqA6Jf=UPS+tyUvT_YvuP_grVA@mail.gmail.com> <Z8yxsm9ZWVkHlPbV@nathan> <CACX+KaP+6U9jf=GT4wpR7TvRvSMtTAhz=vP2Zr+ZdUFVZzqNsA@mail.gmail.com> <Z8y9RTT-vU6oVI_Y@nathan>
Comments: In-reply-to Nathan Bossart <nathandbossart@gmail.com>
	message dated "Sat, 08 Mar 2025 15:57:25 -0600"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <149428.1741472260.1@sss.pgh.pa.us>
Date: Sat, 08 Mar 2025 17:17:40 -0500
Message-ID: <149429.1741472260@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/149429.1741472260%40sss.pgh.pa.us>
Precedence: bulk

Nathan Bossart <nathandbossart@gmail.com> writes:
> I do see a concern upthread about increased deadlock risk [0], but your
> patch doesn't lock the table, but unless I'm wrong [1] (which is always
> possible), it doesn't need to lock it.

It bothers me a bit that this proposes to do something as complicated
as pg_class_aclcheck on a table we have no lock on.  As you say, the
lock we hold on the index would prevent DROP TABLE, but that doesn't
mean we won't have any issues with other DDL on the table.  Still,
taking a lock would be bad because of the deadlock hazard, and I
think the potential for conflicts with concurrent DDL is nonzero in
a lot of other places.  So I don't have any concrete reason to object.

ReindexIndex() faces this same problem and solves it with some
very complex code that manages to get the table's lock first.
But I see that it's also doing pg_class_aclcheck on a table
it hasn't locked yet, so I don't think that adopting its approach
would do anything useful for us here.

			regards, tom lane