try_relation_open and relation_open behave different.

From: Xing GUO <higuoxing(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: try_relation_open and relation_open behave different.
Date: 2021-10-18 05:56:07
Message-ID: CACpMh+C00FnGkW=qPX7UQxSWh0Xhz-Nx5tJr+SpMjcmsUXDnJQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

I'm writing an extension that employs `object_access_hook`. I want to
monitor the table creation event and record the mapping between `reloid`
and `relfilenode` during a transaction. Here's my code snippet,

```
static void
my_object_access_hook(ObjectAccessType access,
Oid classId,
Oid objectId,
int subId, void *arg)
{
do_some_checks(access, classId, ...);
// open the relation using relation_open
rel = relation_open(objectId, AccessShareLock);

// record the reloid and relfilenode.
record(objectId, rel->rd_node);
relation_close(rel, AccessShareLock);
}
```

However, when I replace the relation_open with try_relation_open, the
relation cannot be opened. I've checked the source code, it looks that
try_relation_open has an additional checker which causes the relation_open
and try_relation_open behavior different:

```
Relation
try_relation_open(Oid relationId, LOCKMODE lockmode)
{
...
/*
* Now that we have the lock, probe to see if the relation really exists
* or not.
*/
if (!SearchSysCacheExists1(RELOID, ObjectIdGetDatum(relationId)))
{
/* Release useless lock */
if (lockmode != NoLock)
UnlockRelationOid(relationId, lockmode);

return NULL;
}
...
}
```

See:
https://github.com/postgres/postgres/blob/c30f54ad732ca5c8762bb68bbe0f51de9137dd72/src/backend/access/common/relation.c#L47

My question is, is it a deliberate design that makes try_relation_open and
relation_open different? Shall we mention it in the comment of
try_relation_open OR adding the checker to relation_open?

Best Regards,
Xing

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-10-18 06:00:43 Re: Data is copied twice when specifying both child and parent table in publication
Previous Message Bharath Rupireddy 2021-10-18 05:41:58 Re: can we add subscription TAP test option "vcregress subscriptioncheck" for MSVC builds?