This is an automated email from the ASF dual-hosted git repository. leborchuk pushed a commit to branch REL_2_STABLE in repository https://gitbox.apache.org/repos/asf/cloudberry.git
commit c947907d45311014282b497b4d0b1d5fef9b7134 Author: Tom Lane <[email protected]> AuthorDate: Fri Dec 15 13:55:05 2023 -0500 Fix bugs in manipulation of large objects. In v16 and up (since commit afbfc0298), large object ownership checking has been broken because object_ownercheck() didn't take care of the discrepancy between our object-address representation of large objects (classId == LargeObjectRelationId) and the catalog where their ownership 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_internal would pass the wrong classId to the PostAlterHook in the no-op code path where the large object already has the desired owner. Also, recordExtObjInitPriv checked for the wrong classId; that bug is only latent because the stanza is dead code anyway, but as long as we're carrying 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 by changing AlterObjectOwner_internal's API to let the translation happen inside that function, rather than requiring callers to know about it. A more bulletproof fix, perhaps, would be to start using LargeObjectMetadataRelationId as the dependency and object-address classId for blobs. However that has substantial risk of breaking third-party code; even within our own code, it'd create hassles for pg_dump which would have to cope with a version-dependent representation. For now, keep the status quo. Discussion: https://postgr.es/m/[email protected] (cherry picked from commit f552f2be2410632f59effffe8ba736c523de6b4c) --- src/backend/catalog/aclchk.c | 4 ++-- src/backend/commands/alter.c | 17 ++++++++++++++++- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c index 44011306df2..73ad7d1e416 100644 --- a/src/backend/catalog/aclchk.c +++ b/src/backend/catalog/aclchk.c @@ -6437,9 +6437,9 @@ recordExtObjInitPriv(Oid objoid, Oid classoid) ReleaseSysCache(tuple); } - /* pg_largeobject_metadata */ - else if (classoid == LargeObjectMetadataRelationId) + else if (classoid == LargeObjectRelationId) { + /* For large objects, we must consult pg_largeobject_metadata */ Datum aclDatum; bool isNull; HeapTuple tuple; diff --git a/src/backend/commands/alter.c b/src/backend/commands/alter.c index 6f370a2c9aa..59d4c3c220d 100644 --- a/src/backend/commands/alter.c +++ b/src/backend/commands/alter.c @@ -1182,9 +1182,14 @@ AlterObjectOwner_internal(Relation rel, Oid objectId, Oid new_ownerId) /* Perform actual update */ CatalogTupleUpdate(rel, &newtup->t_self, newtup); - /* Update owner dependency reference */ + /* + * Update owner dependency reference. When working on a large object, + * we have to translate back to the OID conventionally used for LOs' + * classId. + */ if (classId == LargeObjectMetadataRelationId) classId = LargeObjectRelationId; + changeDependencyOnOwner(classId, objectId, new_ownerId); /* Release memory */ @@ -1192,6 +1197,16 @@ AlterObjectOwner_internal(Relation rel, Oid objectId, Oid new_ownerId) pfree(nulls); pfree(replaces); } + else + { + /* + * No need to change anything. But when working on a large object, we + * have to translate back to the OID conventionally used for LOs' + * classId, or the post-alter hook (if any) will get confused. + */ + if (classId == LargeObjectMetadataRelationId) + classId = LargeObjectRelationId; + } InvokeObjectPostAlterHook(classId, objectId, 0); } --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
