Lock the extension during ALTER EXTENSION ADD/DROP.

Although we were careful to lock the object being added or dropped,
we failed to get any sort of lock on the extension itself.  This
allowed the ALTER to proceed in parallel with a DROP EXTENSION,
which is problematic for a couple of reasons.  If both commands
succeeded we'd be left with a dangling link in pg_depend, which
would cause problems later.  Also, if the ALTER failed for some
reason, it might try to print the extension's name, and that could
result in a crash or (in older branches) a silly error message
complaining about extension "(null)".

Per bug #17098 from Alexander Lakhin.  Back-patch to all
supported branches.

Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org
This commit is contained in:
Tom Lane 2021-07-11 12:54:24 -04:00
parent 5b1621d2fb
commit 92340ba5a7
1 changed files with 11 additions and 3 deletions

View File

@ -3200,9 +3200,17 @@ ExecAlterExtensionContentsStmt(AlterExtensionContentsStmt *stmt,
Relation relation;
Oid oldExtension;
extension.classId = ExtensionRelationId;
extension.objectId = get_extension_oid(stmt->extname, false);
extension.objectSubId = 0;
/*
* Find the extension and acquire a lock on it, to ensure it doesn't get
* dropped concurrently. A sharable lock seems sufficient: there's no
* reason not to allow other sorts of manipulations, such as add/drop of
* other objects, to occur concurrently. Concurrently adding/dropping the
* *same* object would be bad, but we prevent that by using a non-sharable
* lock on the individual object, below.
*/
extension = get_object_address(OBJECT_EXTENSION,
(Node *) makeString(stmt->extname),
&relation, AccessShareLock, false);
/* Permission check: must own extension */
if (!pg_extension_ownercheck(extension.objectId, GetUserId()))