Horton
Menu

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Detect POLLHUP/POLLRDHUP while running queries.

  1. try_relation_open and relation_open behave different.

    Xing Guo <higuoxing@gmail.com> — 2021-10-18T05:56:07Z

    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

  2. Re: try_relation_open and relation_open behave different.

    Michael Paquier <michael@paquier.xyz> — 2021-10-18T06:45:10Z

    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

  3. Re: try_relation_open and relation_open behave different.

    Xing Guo <higuoxing@gmail.com> — 2021-10-18T07:38:13Z

    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.


> --
> Michael
>

  4. Re: try_relation_open and relation_open behave different.

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2021-10-18T13:44:24Z

    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)