try_relation_open and relation_open behave different.
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;
}
...
}
```
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
On Mon, Oct 18, 2021 at 01:56:07PM +0800, Xing GUO wrote:
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?
I am not sure what you mean here, both functions are include comments
to explain their differences, so..
--
Michael
On Mon, Oct 18, 2021 at 2:45 PM Michael Paquier <michael@paquier.xyz> wrote:
On Mon, Oct 18, 2021 at 01:56:07PM +0800, Xing GUO wrote:
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?I am not sure what you mean here, both functions are include comments
to explain their differences, so..
The comments in try_relation_open says:
```
/* ----------------
* try_relation_open - open any relation by relation OID
*
* Same as relation_open, except return NULL instead of failing
* if the relation does not exist.
* ----------------
*/
```
However, I can open an "uncommitted" relation using relation_open() and
cannot open it using try_relation_open().
Since Postgres doesn't write the "uncommitted" relation descriptor to
SysCache and try_relation_open() checks if the
relation exists in SysCache while relation_open() doesn't check it.
Show quoted text
--
Michael
On 2021-Oct-18, Xing GUO wrote:
However, I can open an "uncommitted" relation using relation_open() and
cannot open it using try_relation_open().
Since Postgres doesn't write the "uncommitted" relation descriptor to
SysCache and try_relation_open() checks if the
relation exists in SysCache while relation_open() doesn't check it.
Hmm, is it sufficient to do CommandCounterIncrement() after your
"uncommitted" relation change and the place where you do
try_relation_open()?
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Linux transformó mi computadora, de una `máquina para hacer cosas',
en un aparato realmente entretenido, sobre el cual cada día aprendo
algo nuevo" (Jaime Salinas)