Re: Unify drop-by-OID functions
On 2020-05-05 18:05, Robert Haas wrote: This reminds me: I think that the issues in http://postgr.es/m/ca+tgmoyafyrrdrz94p_qdt+1oong6smovbkghkvsftoncrf...@mail.gmail.com should be considered here - we should guarantee that there's a snapshot registered continuously from before the call to SearchSysCache1 until after the call to CatalogTupleDelete. In the systable_beginscan case, we should be fine as long as the systable_endscan follows the CatalogTupleDelete call. I considered this, but it seems independent of my patch. If there are changes to be made, there are now fewer places to fix up. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Unify drop-by-OID functions
On 2020-05-04 20:57, Peter Eisentraut wrote: New patch attached. I'll park it until PG14 opens. committed -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Unify drop-by-OID functions
Only as a homework, is this function completely useless? ItemPointerData systable_scan_next(Relation heapRelation, Oid indexId, bool indexOK, Snapshot snapshot, int nkeys, ScanKey key) { SysScanDesc scan; HeapTuple htup; ItemPointerData tid; scan = systable_beginscan(heapRelation, indexId, indexOK, snapshot, nkeys, key); htup = systable_getnext(scan); if (HeapTupleIsValid(htup)) tid = >t_self; else tid = NULL; systable_endscan(scan); return tid; } regards, Ranier Vilela
Re: Unify drop-by-OID functions
Em ter., 5 de mai. de 2020 às 18:11, Alvaro Herrera < alvhe...@2ndquadrant.com> escreveu: > On 2020-May-05, Ranier Vilela wrote: > > > And in that specific case, leaving resources blocked, which perhaps, in > my > > humble opinion, could be released quickly. > > I very much doubt that you can measure any difference at all between > these two codings of the function. > > I agree with the principle you mention, of not holding resources for > long if they can be released earlier; but in this case the table_close > call occurs across a ReleaseSysCache() call, which is hardly of > significance. It's not like you have to wait for some other > transaction, or wait for I/O, or anything like that that would make it > measurable. > Locally it may not be as efficient, but it is a question, to follow the good programming practices, among them, not to break anything, not to block, and if it is not possible, release soon. In at least one case, there will not even be a block, which is an improvement. Another version, that could, be, without using ERROR. +static void +DropObjectById(const ObjectAddress *object) +{ + int cacheId; + Relation rel; + HeapTuple tup; + + cacheId = get_object_catcache_oid(object->classId); + + /* + * Use the system cache for the oid column, if one exists. + */ + if (cacheId >= 0) + { + tup = SearchSysCache1(cacheId, ObjectIdGetDatum(object->objectId)); + if (HeapTupleIsValid(tup)) { +rel = table_open(object->classId, RowExclusiveLock); +CatalogTupleDelete(rel, >t_self); +table_close(rel, RowExclusiveLock); +ReleaseSysCache(tup); + } + else + elog(LOG, "cache lookup failed for %s %u", + get_object_class_descr(object->classId), object->objectId); + } + else + { + ScanKeyData skey[1]; + SysScanDesc scan; + + ScanKeyInit([0], + get_object_attnum_oid(object->classId), + BTEqualStrategyNumber, F_OIDEQ, + ObjectIdGetDatum(object->objectId)); + +rel = table_open(object->classId, RowExclusiveLock); + scan = systable_beginscan(rel, get_object_oid_index(object->classId), true, + NULL, 1, skey); + + /* we expect exactly one match */ + tup = systable_getnext(scan); + if (HeapTupleIsValid(tup)) +CatalogTupleDelete(rel, >t_self); + else + elog(LOG, "could not find tuple for %s %u", + get_object_class_descr(object->classId), object->objectId); + +systable_endscan(scan); +table_close(rel, RowExclusiveLock); + } +} + regards, Ranier Vilela
Re: Unify drop-by-OID functions
On 2020-May-05, Ranier Vilela wrote: > And in that specific case, leaving resources blocked, which perhaps, in my > humble opinion, could be released quickly. I very much doubt that you can measure any difference at all between these two codings of the function. I agree with the principle you mention, of not holding resources for long if they can be released earlier; but in this case the table_close call occurs across a ReleaseSysCache() call, which is hardly of significance. It's not like you have to wait for some other transaction, or wait for I/O, or anything like that that would make it measurable. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Unify drop-by-OID functions
Em ter., 5 de mai. de 2020 às 14:57, Robert Haas escreveu: > On Tue, May 5, 2020 at 1:43 PM Ranier Vilela wrote: > > I see, the famous "cliché". > > By using the word cliché, and by putting it in quotes, you seem to > suggest that you consider my argument dubious. However, I stand by it. > Code shouldn't be changed without understanding the reasons behind the > current coding. Doing so very often breaks things. > Sorry Robert, It was not my intention. I didn't know that using quotes would change your understanding. Of course, I find your arguments very valid and valuable. And I understand that there are many interrelated things, which can break if done in the wrong order. Maybe I used the wrong word, in this case, the cliché. What I mean is, the cliché, does some strange things, like leaving variables to be declared, assigned in and not used. And in that specific case, leaving resources blocked, which perhaps, in my humble opinion, could be released quickly. I think the expected behavior is being the same, with the changes I proposed, IMHO. +static void +DropObjectById(const ObjectAddress *object) +{ + int cacheId; + Relation rel; + HeapTuple tup; + + cacheId = get_object_catcache_oid(object->classId); + + /* + * Use the system cache for the oid column, if one exists. + */ + if (cacheId >= 0) + { + tup = SearchSysCache1(cacheId, ObjectIdGetDatum(object->objectId)); + if (!HeapTupleIsValid(tup)) + elog(ERROR, "cache lookup failed for %s %u", + get_object_class_descr(object->classId), object->objectId); + +rel = table_open(object->classId, RowExclusiveLock); + CatalogTupleDelete(rel, >t_self); +table_close(rel, RowExclusiveLock); + + ReleaseSysCache(tup); + } + else + { + ScanKeyData skey[1]; + SysScanDesc scan; + + ScanKeyInit([0], + get_object_attnum_oid(object->classId), + BTEqualStrategyNumber, F_OIDEQ, + ObjectIdGetDatum(object->objectId)); + +rel = table_open(object->classId, RowExclusiveLock); + scan = systable_beginscan(rel, get_object_oid_index(object->classId), true, + NULL, 1, skey); + + /* we expect exactly one match */ + tup = systable_getnext(scan); + if (!HeapTupleIsValid(tup)) + elog(ERROR, "could not find tuple for %s %u", + get_object_class_descr(object->classId), object->objectId); + + CatalogTupleDelete(rel, >t_self); + systable_endscan(scan); + +table_close(rel, RowExclusiveLock); + } +} And again, your opinion is very important to me. best regards, Ranier Vilela
Re: Unify drop-by-OID functions
On Tue, May 5, 2020 at 1:43 PM Ranier Vilela wrote: > I see, the famous "cliché". By using the word cliché, and by putting it in quotes, you seem to suggest that you consider my argument dubious. However, I stand by it. Code shouldn't be changed without understanding the reasons behind the current coding. Doing so very often breaks things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Unify drop-by-OID functions
Em ter., 5 de mai. de 2020 às 14:29, Robert Haas escreveu: > On Tue, May 5, 2020 at 1:22 PM Ranier Vilela wrote: > > Ok, so the question. If (3) is not safe, obvious we shouldn't use, and > must call table_close, after systable_endscan. > > Now (1) and (2), I would have no hesitation in using it. > > I work with ERP, and throughout the time, the later, lock resources and > release them soon, the better, for the performance of the system as a whole. > > Even if it doesn't make much difference locally, using this process, > throughout the system, efficiency is noticeable. > > Apparently, it is more code, but it is less resources used and for less > time. > > And (2), if it is a case, frequently, no table would be blocked in this > function. > > Nobody here is going to question the concept that it's better to use > resources for less time rather than more, but the wisdom of sticking > to well-established coding patterns instead of inventing altogether > new ones is also well-understood. There are often good reasons why the > code is written in the way that it is, and it's important to > understand those before proposing to change things. > I see, the famous "cliché". regards, Ranier Vilela > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
Re: Unify drop-by-OID functions
On Tue, May 5, 2020 at 1:22 PM Ranier Vilela wrote: > Ok, so the question. If (3) is not safe, obvious we shouldn't use, and must > call table_close, after systable_endscan. > Now (1) and (2), I would have no hesitation in using it. > I work with ERP, and throughout the time, the later, lock resources and > release them soon, the better, for the performance of the system as a whole. > Even if it doesn't make much difference locally, using this process, > throughout the system, efficiency is noticeable. > Apparently, it is more code, but it is less resources used and for less time. > And (2), if it is a case, frequently, no table would be blocked in this > function. Nobody here is going to question the concept that it's better to use resources for less time rather than more, but the wisdom of sticking to well-established coding patterns instead of inventing altogether new ones is also well-understood. There are often good reasons why the code is written in the way that it is, and it's important to understand those before proposing to change things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Unify drop-by-OID functions
Em ter., 5 de mai. de 2020 às 13:06, Robert Haas escreveu: > On Fri, May 1, 2020 at 5:32 PM Ranier Vilela wrote: > > I can suggest improvements? > > > > 1. In case Object is cached, delay open_table until the last moment, for > the row to be blocked as little as possible and close the table as quickly > as possible. > > 2. In case Object is cached and the tuple is invalid, do not open table. > > 3. Otherwise, is it possible to call systable_endscan, after table_close? > > > > I think that lock resources, for as little time as possible, it is an > advantage.. > > Only if it's correct, which (3) definitely wouldn't be, and I'm > doubtful about (1) as well. > Ok, so the question. If (3) is not safe, obvious we shouldn't use, and must call table_close, after systable_endscan. Now (1) and (2), I would have no hesitation in using it. I work with ERP, and throughout the time, the later, lock resources and release them soon, the better, for the performance of the system as a whole. Even if it doesn't make much difference locally, using this process, throughout the system, efficiency is noticeable. Apparently, it is more code, but it is less resources used and for less time. And (2), if it is a case, frequently, no table would be blocked in this function. Simple examples. Exemple 1: FILE * f; f = fopen("data.txt", "r"); if (f != NULL) { char buf[512]; size_t result; result = fread(, sizeof(char), 512, f); fclose(f); // we no longer need the resource, release. if (result != 0) { process(buf); printf("buf=%s\n", buf); } } Exemple 2: FILE * f; f = fopen("data.txt", "r"); if (f != NULL) { char buf[512]; size_t result; result = fread(, sizeof(char), 512, f); if (result != 0) { process(buf); printf("buf=%s\n", buf); } fclose(f); // resource blocked until the end. } regards, Ranier Vilela
Re: Unify drop-by-OID functions
On Fri, May 1, 2020 at 5:32 PM Ranier Vilela wrote: > I can suggest improvements? > > 1. In case Object is cached, delay open_table until the last moment, for the > row to be blocked as little as possible and close the table as quickly as > possible. > 2. In case Object is cached and the tuple is invalid, do not open table. > 3. Otherwise, is it possible to call systable_endscan, after table_close? > > I think that lock resources, for as little time as possible, it is an > advantage.. Only if it's correct, which (3) definitely wouldn't be, and I'm doubtful about (1) as well. This reminds me: I think that the issues in http://postgr.es/m/ca+tgmoyafyrrdrz94p_qdt+1oong6smovbkghkvsftoncrf...@mail.gmail.com should be considered here - we should guarantee that there's a snapshot registered continuously from before the call to SearchSysCache1 until after the call to CatalogTupleDelete. In the systable_beginscan case, we should be fine as long as the systable_endscan follows the CatalogTupleDelete call. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Unify drop-by-OID functions
On 2020-05-01 17:44, Robert Haas wrote: On Fri, May 1, 2020 at 10:51 AM Pavel Stehule wrote: +1 +1 from me, too, but I have a few suggestions: +DropGenericById(const ObjectAddress *object) How about "Generic" -> "Object" or "Generic" -> "ObjectAddress"? Changed to "Object", that also matches existing functions that operate on an ObjectAddress. + elog(ERROR, "cache lookup failed for %s entry %u", + elog(ERROR, "could not find tuple for class %u entry %u", How about "entry" -> "with OID"? I changed these to just "cache lookup failed for %s %u" "could not find tuple for %s %u" which matches the existing wording for the not-refactored cases. I don't recall why I went and reworded them. New patch attached. I'll park it until PG14 opens. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services From 0916fd395efe65f280c3acdb2172953adbb34afa Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Mon, 4 May 2020 20:22:44 +0200 Subject: [PATCH v2] Unify drop-by-OID functions There are a number of Remove${Something}ById() functions that are essentially identical in structure and only different in which catalog they are working on. Refactor this to be one generic function. The information about which oid column, index, etc. to use was already available in ObjectProperty for most catalogs, in a few cases it was easily added. --- src/backend/catalog/aclchk.c | 33 - src/backend/catalog/dependency.c | 160 - src/backend/catalog/objectaddress.c| 99 ++- src/backend/catalog/pg_collation.c | 36 -- src/backend/catalog/pg_conversion.c| 33 - src/backend/commands/amcmds.c | 27 - src/backend/commands/event_trigger.c | 22 src/backend/commands/foreigncmds.c | 71 --- src/backend/commands/functioncmds.c| 53 src/backend/commands/opclasscmds.c | 99 --- src/backend/commands/proclang.c| 22 src/backend/commands/publicationcmds.c | 23 src/backend/commands/schemacmds.c | 23 src/backend/commands/tsearchcmds.c | 71 --- src/include/catalog/objectaddress.h| 1 + src/include/catalog/pg_collation.h | 1 - src/include/catalog/pg_conversion.h| 1 - src/include/commands/defrem.h | 13 -- src/include/commands/event_trigger.h | 1 - src/include/commands/proclang.h| 1 - src/include/commands/publicationcmds.h | 1 - src/include/commands/schemacmds.h | 2 - src/include/utils/acl.h| 1 - 23 files changed, 175 insertions(+), 619 deletions(-) diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c index cb2c4972ad..c626161408 100644 --- a/src/backend/catalog/aclchk.c +++ b/src/backend/catalog/aclchk.c @@ -1498,39 +1498,6 @@ RemoveRoleFromObjectACL(Oid roleid, Oid classid, Oid objid) } -/* - * Remove a pg_default_acl entry - */ -void -RemoveDefaultACLById(Oid defaclOid) -{ - Relationrel; - ScanKeyData skey[1]; - SysScanDesc scan; - HeapTuple tuple; - - rel = table_open(DefaultAclRelationId, RowExclusiveLock); - - ScanKeyInit([0], - Anum_pg_default_acl_oid, - BTEqualStrategyNumber, F_OIDEQ, - ObjectIdGetDatum(defaclOid)); - - scan = systable_beginscan(rel, DefaultAclOidIndexId, true, - NULL, 1, skey); - - tuple = systable_getnext(scan); - - if (!HeapTupleIsValid(tuple)) - elog(ERROR, "could not find tuple for default ACL %u", defaclOid); - - CatalogTupleDelete(rel, >t_self); - - systable_endscan(scan); - table_close(rel, RowExclusiveLock); -} - - /* * expand_col_privileges * diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c index ffd52c1153..502d3684b4 100644 --- a/src/backend/catalog/dependency.c +++ b/src/backend/catalog/dependency.c @@ -66,9 +66,7 @@ #include "commands/event_trigger.h" #include "commands/extension.h" #include "commands/policy.h" -#include "commands/proclang.h" #include "commands/publicationcmds.h" -#include "commands/schemacmds.h" #include "commands/seclabel.h" #include "commands/sequence.h" #include "commands/trigger.h" @@ -1225,6 +1223,62 @@ reportDependentObjects(const ObjectAddresses *targetObjects, pfree(logdetail.data); } +/* + * Drop an object by OID. Works for most catalogs, if no special processing + * is needed. + */ +static void +DropObjectById(const ObjectAddress *object) +{ + int cacheId; +
Re: Unify drop-by-OID functions
Em sáb., 2 de mai. de 2020 às 05:01, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> escreveu: > On 2020-05-01 23:31, Ranier Vilela wrote: > > I can suggest improvements? > > > > 1. In case Object is cached, delay open_table until the last moment, for > > the row to be blocked as little as possible and close the table as > > quickly as possible. > > 2. In case Object is cached and the tuple is invalid, do not open table. > > 3. Otherwise, is it possible to call systable_endscan, after table_close? > > What do you mean by "object is cached"? > Well, that's what I deduced from the cacheId variable name. regards, Ranier Vilela
Re: Unify drop-by-OID functions
On 2020-05-01 23:31, Ranier Vilela wrote: I can suggest improvements? 1. In case Object is cached, delay open_table until the last moment, for the row to be blocked as little as possible and close the table as quickly as possible. 2. In case Object is cached and the tuple is invalid, do not open table. 3. Otherwise, is it possible to call systable_endscan, after table_close? What do you mean by "object is cached"? In any case, this is a refactoring patch, so significant changes to the internal logic would not really be in scope. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Re: Unify drop-by-OID functions
Em sex., 1 de mai. de 2020 às 11:39, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> escreveu: > [proposal for PG 14] > > There are a number of Remove${Something}ById() functions that are > essentially identical in structure and only different in which catalog > they are working on. This patch refactors this to be one generic > function. The information about which oid column, index, etc. to use > was already available in ObjectProperty for most catalogs, in a few > cases it was easily added. > > Conceivably, this could be taken further by categorizing more special > cases as ObjectProperty fields or something like that, but this seemed > like a good balance. > Very good. I can suggest improvements? 1. In case Object is cached, delay open_table until the last moment, for the row to be blocked as little as possible and close the table as quickly as possible. 2. In case Object is cached and the tuple is invalid, do not open table. 3. Otherwise, is it possible to call systable_endscan, after table_close? I think that lock resources, for as little time as possible, it is an advantage.. +static void +DropGenericById(const ObjectAddress *object) +{ + int cacheId; + Relation rel; + HeapTuple tup; + + cacheId = get_object_catcache_oid(object->classId); + + /* + * Use the system cache for the oid column, if one exists. + */ + if (cacheId >= 0) + { + tup = SearchSysCache1(cacheId, ObjectIdGetDatum(object->objectId)); + if (!HeapTupleIsValid(tup)) + elog(ERROR, "cache lookup failed for %s entry %u", + get_object_class_descr(object->classId), object->objectId); + +rel = table_open(object->classId, RowExclusiveLock); + CatalogTupleDelete(rel, >t_self); +table_close(rel, RowExclusiveLock); + + ReleaseSysCache(tup); + } + else + { + ScanKeyData skey[1]; + SysScanDesc scan; + + ScanKeyInit([0], + get_object_attnum_oid(object->classId), + BTEqualStrategyNumber, F_OIDEQ, + ObjectIdGetDatum(object->objectId)); + +rel = table_open(object->classId, RowExclusiveLock); + scan = systable_beginscan(rel, get_object_oid_index(object->classId), true, + NULL, 1, skey); + + /* we expect exactly one match */ + tup = systable_getnext(scan); + if (!HeapTupleIsValid(tup)) + elog(ERROR, "could not find tuple for class %u entry %u", + object->classId, object->objectId); + + CatalogTupleDelete(rel, >t_self); + systable_endscan(scan); +table_close(rel, RowExclusiveLock); + } +} + regards, Ranier Vilela
Re: Unify drop-by-OID functions
On Fri, May 1, 2020 at 10:51 AM Pavel Stehule wrote: > +1 +1 from me, too, but I have a few suggestions: +DropGenericById(const ObjectAddress *object) How about "Generic" -> "Object" or "Generic" -> "ObjectAddress"? + elog(ERROR, "cache lookup failed for %s entry %u", + elog(ERROR, "could not find tuple for class %u entry %u", How about "entry" -> "with OID"? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Re: Unify drop-by-OID functions
pá 1. 5. 2020 v 16:39 odesílatel Peter Eisentraut < peter.eisentr...@2ndquadrant.com> napsal: > [proposal for PG 14] > > There are a number of Remove${Something}ById() functions that are > essentially identical in structure and only different in which catalog > they are working on. This patch refactors this to be one generic > function. The information about which oid column, index, etc. to use > was already available in ObjectProperty for most catalogs, in a few > cases it was easily added. > > Conceivably, this could be taken further by categorizing more special > cases as ObjectProperty fields or something like that, but this seemed > like a good balance. > +1 nice Pavel > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >
Unify drop-by-OID functions
[proposal for PG 14] There are a number of Remove${Something}ById() functions that are essentially identical in structure and only different in which catalog they are working on. This patch refactors this to be one generic function. The information about which oid column, index, etc. to use was already available in ObjectProperty for most catalogs, in a few cases it was easily added. Conceivably, this could be taken further by categorizing more special cases as ObjectProperty fields or something like that, but this seemed like a good balance. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services From a4d3112c9385e3f489f9327e58c0995f51e003f4 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut Date: Fri, 1 May 2020 13:29:38 +0200 Subject: [PATCH] Unify drop-by-OID functions There are a number of Remove${Something}ById() functions that are essentially identical in structure and only different in which catalog they are working on. Refactor this to be one generic function. The information about which oid column, index, etc. to use was already available in ObjectProperty for most catalogs, in a few cases it was easily added. --- src/backend/catalog/aclchk.c | 33 - src/backend/catalog/dependency.c | 160 - src/backend/catalog/objectaddress.c| 99 ++- src/backend/catalog/pg_collation.c | 36 -- src/backend/catalog/pg_conversion.c| 33 - src/backend/commands/amcmds.c | 27 - src/backend/commands/event_trigger.c | 22 src/backend/commands/foreigncmds.c | 71 --- src/backend/commands/functioncmds.c| 53 src/backend/commands/opclasscmds.c | 99 --- src/backend/commands/proclang.c| 22 src/backend/commands/publicationcmds.c | 23 src/backend/commands/schemacmds.c | 23 src/backend/commands/tsearchcmds.c | 71 --- src/include/catalog/objectaddress.h| 1 + src/include/catalog/pg_collation.h | 1 - src/include/catalog/pg_conversion.h| 1 - src/include/commands/defrem.h | 13 -- src/include/commands/event_trigger.h | 1 - src/include/commands/proclang.h| 1 - src/include/commands/publicationcmds.h | 1 - src/include/commands/schemacmds.h | 2 - src/include/utils/acl.h| 1 - 23 files changed, 175 insertions(+), 619 deletions(-) diff --git a/src/backend/catalog/aclchk.c b/src/backend/catalog/aclchk.c index cb2c4972ad..c626161408 100644 --- a/src/backend/catalog/aclchk.c +++ b/src/backend/catalog/aclchk.c @@ -1498,39 +1498,6 @@ RemoveRoleFromObjectACL(Oid roleid, Oid classid, Oid objid) } -/* - * Remove a pg_default_acl entry - */ -void -RemoveDefaultACLById(Oid defaclOid) -{ - Relationrel; - ScanKeyData skey[1]; - SysScanDesc scan; - HeapTuple tuple; - - rel = table_open(DefaultAclRelationId, RowExclusiveLock); - - ScanKeyInit([0], - Anum_pg_default_acl_oid, - BTEqualStrategyNumber, F_OIDEQ, - ObjectIdGetDatum(defaclOid)); - - scan = systable_beginscan(rel, DefaultAclOidIndexId, true, - NULL, 1, skey); - - tuple = systable_getnext(scan); - - if (!HeapTupleIsValid(tuple)) - elog(ERROR, "could not find tuple for default ACL %u", defaclOid); - - CatalogTupleDelete(rel, >t_self); - - systable_endscan(scan); - table_close(rel, RowExclusiveLock); -} - - /* * expand_col_privileges * diff --git a/src/backend/catalog/dependency.c b/src/backend/catalog/dependency.c index ffd52c1153..2d208d5ee2 100644 --- a/src/backend/catalog/dependency.c +++ b/src/backend/catalog/dependency.c @@ -66,9 +66,7 @@ #include "commands/event_trigger.h" #include "commands/extension.h" #include "commands/policy.h" -#include "commands/proclang.h" #include "commands/publicationcmds.h" -#include "commands/schemacmds.h" #include "commands/seclabel.h" #include "commands/sequence.h" #include "commands/trigger.h" @@ -1225,6 +1223,62 @@ reportDependentObjects(const ObjectAddresses *targetObjects, pfree(logdetail.data); } +/* + * Drop an object by OID. Works for most catalogs, if no special processing + * is needed. + */ +static void +DropGenericById(const ObjectAddress *object) +{ + int cacheId; + Relationrel; + HeapTuple tup; + + cacheId = get_object_catcache_oid(object->classId); + + rel = table_open(object->classId, RowExclusiveLock); + + /* +* Use the system cache for the oid column, if one exists. +*/ + if (cacheId >= 0) + { +