From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
cc: Nathan Bossart <nathandbossart@gmail.com>,
        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: <67e077fcfe474ce7c56d36492d89c150768271e1.camel@j-davis.com>
References: <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> <149429.1741472260@sss.pgh.pa.us> <Z8zwVmGzXyDdkAXj@nathan> <279947.1741535285@sss.pgh.pa.us> <Z88CB-vDehJ9rW8u@nathan> <aNQVIVKarUipPcnW@nathan> <3432170.1758730414@sss.pgh.pa.us> <67e077fcfe474ce7c56d36492d89c150768271e1.camel@j-davis.com>
Comments: In-reply-to Jeff Davis <pgsql@j-davis.com>
	message dated "Mon, 13 Oct 2025 11:16:36 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <718743.1760390467.1@sss.pgh.pa.us>
Date: Mon, 13 Oct 2025 17:21:07 -0400
Message-ID: <718744.1760390467@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/718744.1760390467%40sss.pgh.pa.us>
Precedence: bulk

Jeff Davis <pgsql@j-davis.com> writes:
> On Wed, 2025-09-24 at 12:13 -0400, Tom Lane wrote:
>> Don't we do that intentionally, to make sure someone can't cause DOS
>> on a table they have no privileges on?

> Is this only a problem for strong locks (ShareLock or greater)?

> Strong locks are a problem when you have a pattern like a long running
> query that holds an AccessShareLock, and then an unprivileged user
> requests an AccessExclusiveLock, forcing other queries to queue up
> behind it, and the queue doesn't clear until the long running query
> finishes.

> But weaker locks don't seem to have that problem, right?

I don't think so.  Even AccessShareLock is enough to block another
session trying to acquire AccessExclusiveLock, and then not only
have you DoS'd that session, but everything else trying to access
the table will queue up behind the AccessExclusiveLock request.
So it's only not-a-problem if nothing anywhere in the system wants
non-sharable locks.

			regards, tom lane