Possible cache reference leak by removeExtObjInitPriv - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Possible cache reference leak by removeExtObjInitPriv
Date
Msg-id 20200417.151831.1153577605111650154.horikyota.ntt@gmail.com
Whole thread Raw
Responses Re: Possible cache reference leak by removeExtObjInitPriv
List pgsql-hackers
Hello.

Recently a cache reference leak was reported then fixed [1].

I happened to notice a similar possible leakage in
removeEtObjInitPriv. I haven't found a way to reach the code, but can
be forcibly caused by tweaking the condition.

Please find the attached.

regards.

[1]
https://www.postgresql.org/message-id/BYAPR08MB5606D1453D7F50E2AF4D2FD29AD80@BYAPR08MB5606.namprd08.prod.outlook.com

diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c
index a3f680d388..11d9de9031 100644
--- a/src/backend/catalog/aclchk.c
+++ b/src/backend/catalog/aclchk.c
@@ -5869,11 +5869,17 @@ removeExtObjInitPriv(Oid objoid, Oid classoid)
         /* Indexes don't have permissions */
         if (pg_class_tuple->relkind == RELKIND_INDEX ||
             pg_class_tuple->relkind == RELKIND_PARTITIONED_INDEX)
+        {
+            ReleaseSysCache(tuple);
             return;
+        }
 
         /* Composite types don't have permissions either */
         if (pg_class_tuple->relkind == RELKIND_COMPOSITE_TYPE)
+        {
+            ReleaseSysCache(tuple);
             return;
+        }
 
         /*
          * If this isn't a sequence, index, or composite type then it's

pgsql-hackers by date:

Previous
From: Kashif Zeeshan
Date:
Subject: Re: WIP/PoC for parallel backup
Next
From: Masahiko Sawada
Date:
Subject: Re: xid wraparound danger due to INDEX_CLEANUP false