Skip to content

Commit e36fa93

Browse files
peterenmisch
andcommitted
Improve objectNamesToOids() comment
Commit d31bbfb removed the comment at objectNamesToOids() that there is no locking, because that commit added locking. But to fix all the problems, we'd still need a stronger lock. So put the comment back with more a detailed explanation. Co-authored-by: Noah Misch <[email protected]> Reviewed-by: Heikki Linnakangas <[email protected]> Discussion: https://www.postgresql.org/message-id/flat/[email protected]
1 parent 990c8db commit e36fa93

File tree

1 file changed

+14
-0
lines changed

1 file changed

+14
-0
lines changed

src/backend/catalog/aclchk.c

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -659,6 +659,20 @@ ExecGrantStmt_oids(InternalGrant *istmt)
659659
* objectNamesToOids
660660
*
661661
* Turn a list of object names of a given type into an Oid list.
662+
*
663+
* XXX This function intentionally takes only an AccessShareLock. In the face
664+
* of concurrent DDL, we might easily latch onto an old version of an object,
665+
* causing the GRANT or REVOKE statement to fail. But it does prevent the
666+
* object from disappearing altogether. To do better, we would need to use a
667+
* self-exclusive lock, perhaps ShareUpdateExclusiveLock, here and before
668+
* *every* CatalogTupleUpdate() of a row that GRANT/REVOKE can affect.
669+
* Besides that additional work, this could have operational costs. For
670+
* example, it would make GRANT ALL TABLES IN SCHEMA terminate every
671+
* autovacuum running in the schema and consume a shared lock table entry per
672+
* table in the schema. The user-visible benefit of that additional work is
673+
* just changing "ERROR: tuple concurrently updated" to blocking. That's not
674+
* nothing, but it might not outweigh autovacuum termination and lock table
675+
* consumption spikes.
662676
*/
663677
static List *
664678
objectNamesToOids(ObjectType objtype, List *objnames, bool is_grant)

0 commit comments

Comments
 (0)