Re: Unify drop-by-OID functions

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Unify drop-by-OID functions
Date: 2020-05-05 21:51:18
Message-ID: CAEudQAqC0+GWJ-Fiw0M1Nnjy=nCH=+N35U9jUdhsCJh1XzBMrA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em ter., 5 de mai. de 2020 às 18:11, Alvaro Herrera <
alvherre(at)2ndquadrant(dot)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, &tup->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(&skey[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, &tup->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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2020-05-05 21:51:35 Re: xid wraparound danger due to INDEX_CLEANUP false
Previous Message Bruce Momjian 2020-05-05 21:43:35 Re: PG 13 release notes, first draft