Horton

Re: Clarification on Role Access Rights to Table Indexes

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Ayush Vatsa <ayushvatsa1810@gmail.com>, Robert Haas <robertmhaas@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-10-09T15:39:32Z
Lists: pgsql-hackers, pgsql-general 
On Wed, Oct 08, 2025 at 08:28:01PM -0700, Jeff Davis wrote:
> Actually, now I'm unsure. v4-0001 is taking a lock on the table before
> checking privileges, whereas v4-0002 is going to some effort to avoid
> that. Is that because the latter is taking a ShareLock?

I was confused by this, too.  We seem to go to great lengths to avoid
taking a lock before checking permissions in RangeVarGetRelidExtended(),
but in pg_prewarm() and this stats code, we are taking the lock first.
pg_prewarm() can't use RangeVarGetRelid because you give it the OID, but
I'm not seeing why stat_utils.c can't use it.  We should probably fix this.
I wouldn't be surprised if there are other examples.

-- 
nathan

Commits

  1. Fix privilege checks for pg_prewarm() on indexes.

  2. Fix lookup code for REINDEX INDEX.

  3. Fix redefinition of typedef RangeVar.

  4. Fix lookups in pg_{clear,restore}_{attribute,relation}_stats().

  5. dblink: Avoid locking relation before privilege check.