Technical Analysis: dependencyLockAndCheckObject() Terminology Fix
The Core Problem
PostgreSQL's dependency tracking system distinguishes between two roles in a dependency relationship:
- Dependent (or "depender"): The object that depends on another (e.g., a view that references a table)
- Referenced: The object being depended upon (e.g., the table that a view references)
This distinction is fundamental to the pg_depend catalog and the entire DROP CASCADE / RESTRICT logic. When a referenced object is dropped, its dependents must be dropped (CASCADE) or the drop must be refused (RESTRICT). The terminology is precise and well-established throughout the codebase.
A recent back-patched fix (to branches 14-18) added concurrency-safety logic in dependencyLockAndCheckObject(), which locks and verifies that an object still exists before proceeding with dependency operations. When the object has been concurrently dropped, it emits an error message. However, the error message incorrectly stated:
"dependent %s was concurrently dropped"
The problem is that dependencyLockAndCheckObject() is called on referenced objects — the function checks whether the object that is being referenced still exists. One of the callers passes referenced->objectId, and the function's own comment describes it as checking the referenced object. Using "dependent" in the error message is therefore semantically incorrect and potentially confusing for developers debugging concurrency issues in the dependency system.
Why This Matters Architecturally
While this is "just" a terminology fix in an error message, it matters for several reasons:
-
Developer comprehension: The dependency subsystem (
dependency.c) is already one of the most subtle parts of PostgreSQL's catalog management. Incorrect terminology in error messages and comments can mislead developers trying to understand concurrency bugs. -
Back-branch exposure: Since this was back-patched to 14-18, the incorrect message exists across all supported branches, meaning any user or developer encountering a concurrent drop race condition would see a misleading diagnostic.
-
Consistency with existing conventions: PostgreSQL uses "depender" in some places and "dependent" in others (both meaning the object that depends on something else), while "referenced" consistently means the object being depended upon. Mixing these up erodes the terminological discipline that makes the code navigable.
The Fix
The fix is straightforward: change the error message from "dependent %s was concurrently dropped" to "referenced %s was concurrently dropped", and update associated comments to use consistent terminology. This was committed directly by Heikki Linnakangas, the original author of the incorrect message.
Design Context
The dependencyLockAndCheckObject() function exists to handle a TOCTOU race condition in dependency processing: between the time you read pg_depend entries and the time you act on them, the referenced object might be dropped by another session. The function acquires a lock on the object and then re-checks its existence, providing the concurrency safety needed for correct CASCADE/RESTRICT behavior. The error message fires when this re-check discovers the object is gone — which is a valid concurrent scenario that needs clear diagnostic output.