mirror of
https://github.com/postgres/postgres.git
synced 2025-10-18 04:29:09 +03:00
Improve objectNamesToOids() comment
Commit d31bbfb659
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 <noah@leadboat.com>
Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Discussion: https://www.postgresql.org/message-id/flat/bf72b82c-124d-4efa-a484-bb928e9494e4@eisentraut.org
This commit is contained in:
@@ -659,6 +659,20 @@ ExecGrantStmt_oids(InternalGrant *istmt)
|
||||
* objectNamesToOids
|
||||
*
|
||||
* Turn a list of object names of a given type into an Oid list.
|
||||
*
|
||||
* XXX This function intentionally takes only an AccessShareLock. In the face
|
||||
* of concurrent DDL, we might easily latch onto an old version of an object,
|
||||
* causing the GRANT or REVOKE statement to fail. But it does prevent the
|
||||
* object from disappearing altogether. To do better, we would need to use a
|
||||
* self-exclusive lock, perhaps ShareUpdateExclusiveLock, here and before
|
||||
* *every* CatalogTupleUpdate() of a row that GRANT/REVOKE can affect.
|
||||
* Besides that additional work, this could have operational costs. For
|
||||
* example, it would make GRANT ALL TABLES IN SCHEMA terminate every
|
||||
* autovacuum running in the schema and consume a shared lock table entry per
|
||||
* table in the schema. The user-visible benefit of that additional work is
|
||||
* just changing "ERROR: tuple concurrently updated" to blocking. That's not
|
||||
* nothing, but it might not outweigh autovacuum termination and lock table
|
||||
* consumption spikes.
|
||||
*/
|
||||
static List *
|
||||
objectNamesToOids(ObjectType objtype, List *objnames, bool is_grant)
|
||||
|
Reference in New Issue
Block a user