Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitba66f25

Browse files
committed
Fix bugs in manipulation of large objects.
In v16 and up (since commitafbfc02), large object ownershipchecking has been broken because object_ownercheck() didn't take careof the discrepancy between our object-address representation of largeobjects (classId == LargeObjectRelationId) and the catalog where theirownership info is actually stored (LargeObjectMetadataRelationId).This resulted in failures such as "unrecognized class ID: 2613"when trying to update blob properties as a non-superuser.Poking around for related bugs, I found that AlterObjectOwner_internalwould pass the wrong classId to the PostAlterHook in the no-op codepath where the large object already has the desired owner. Also,recordExtObjInitPriv checked for the wrong classId; that bug is onlylatent because the stanza is dead code anyway, but as long as we'recarrying it around it should be less wrong. These bugs are quite old.In HEAD, we can reduce the scope for future bugs of this ilk bychanging AlterObjectOwner_internal's API to let the translation happeninside that function, rather than requiring callers to know about it.A more bulletproof fix, perhaps, would be to start usingLargeObjectMetadataRelationId as the dependency and object-addressclassId for blobs. However that has substantial risk of breakingthird-party code; even within our own code, it'd create hasslesfor pg_dump which would have to cope with a version-dependentrepresentation. For now, keep the status quo.Discussion:https://postgr.es/m/2650449.1702497209@sss.pgh.pa.us
1 parent4d45ecc commitba66f25

File tree

2 files changed

+18
-3
lines changed

2 files changed

+18
-3
lines changed

‎src/backend/catalog/aclchk.c‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -5719,9 +5719,9 @@ recordExtObjInitPriv(Oid objoid, Oid classoid)
57195719

57205720
ReleaseSysCache(tuple);
57215721
}
5722-
/* pg_largeobject_metadata */
5723-
elseif (classoid==LargeObjectMetadataRelationId)
5722+
elseif (classoid==LargeObjectRelationId)
57245723
{
5724+
/* For large objects, we must consult pg_largeobject_metadata */
57255725
DatumaclDatum;
57265726
boolisNull;
57275727
HeapTupletuple;

‎src/backend/commands/alter.c‎

Lines changed: 16 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1035,16 +1035,31 @@ AlterObjectOwner_internal(Relation rel, Oid objectId, Oid new_ownerId)
10351035
/* Perform actual update */
10361036
CatalogTupleUpdate(rel,&newtup->t_self,newtup);
10371037

1038-
/* Update owner dependency reference */
1038+
/*
1039+
* Update owner dependency reference. When working on a large object,
1040+
* we have to translate back to the OID conventionally used for LOs'
1041+
* classId.
1042+
*/
10391043
if (classId==LargeObjectMetadataRelationId)
10401044
classId=LargeObjectRelationId;
1045+
10411046
changeDependencyOnOwner(classId,objectId,new_ownerId);
10421047

10431048
/* Release memory */
10441049
pfree(values);
10451050
pfree(nulls);
10461051
pfree(replaces);
10471052
}
1053+
else
1054+
{
1055+
/*
1056+
* No need to change anything. But when working on a large object, we
1057+
* have to translate back to the OID conventionally used for LOs'
1058+
* classId, or the post-alter hook (if any) will get confused.
1059+
*/
1060+
if (classId==LargeObjectMetadataRelationId)
1061+
classId=LargeObjectRelationId;
1062+
}
10481063

10491064
InvokeObjectPostAlterHook(classId,objectId,0);
10501065
}

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp