Possible cache reference leak by removeExtObjInitPriv
От | Kyotaro Horiguchi |
---|---|
Тема | Possible cache reference leak by removeExtObjInitPriv |
Дата | |
Msg-id | 20200417.151831.1153577605111650154.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответы |
Re: Possible cache reference leak by removeExtObjInitPriv
|
Список | 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 по дате отправления: