dependencyLockAndCheckObject(): dependent vs referenced - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject dependencyLockAndCheckObject(): dependent vs referenced
Date
Msg-id 20260528.114608.488039299811669368.horikyota.ntt@gmail.com
Whole thread
Responses Re: dependencyLockAndCheckObject(): dependent vs referenced
List pgsql-hackers
Recently, the following error message was added in back branches 14-18:

"dependent %s was concurrently dropped"

As I understand it, this is emitted in
dependencyLockAndCheckObject(Oid classId, Oid objectId) when the
object identified by classId/objectId no longer exists at that point.

However, looking at one of the callers:

> void
> recordMultipleDependencies(const ObjectAddress *depender,
>                            const ObjectAddress *referenced,
>                            int nreferenced,
>                            DependencyType behavior)
> {
>     ...
>     dependencyLockAndCheckObject(referenced->classId,
                                 referenced->objectId);

and further up, the function comment says:

> /*
>  * Record a dependency between 2 objects via their respective ObjectAddress.
>  * The first argument is the dependent object, the second the one it
>  * references.
>  *
>  * This simply creates an entry in pg_depend, without any other processing.
>  */
> void
> recordDependencyOn(const ObjectAddress *depender,
>                    const ObjectAddress *referenced,
>                    DependencyType behavior)
> {
>     recordMultipleDependencies(depender, referenced, 1, behavior);
> }

Ignoring higher-level callers for the moment, if this comment is
considered authoritative, then it seems that the object being checked
here is the referenced object rather than the dependent one.

If so, should the message perhaps say:

"referenced %s was concurrently dropped"

instead?

Perhaps the word "dependent" is intentionally being used in a broader
or less strict sense here, but even so, it seems preferable for the
terminology to remain reasonably consistent within this area of the
code, especially since the dependency logic is already fairly subtle.

Regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: injection_points: Switch wait/wakeup to use atomics rather than latches
Next
From: Nisha Moond
Date:
Subject: Re: pg_createsubscriber: Fix incorrect handling of cleanup flags