Incremental Update: Concurrency Concern Resolved
Key Development
Ashutosh Bapat addressed Peter Eisentraut's concurrency/locking concern — the most substantive open issue from the prior analysis — by pointing out that AlterPropGraph already acquires ShareRowExclusiveLock on the property graph relation at the beginning of the function. This lock level is sufficient to serialize concurrent DROP LABEL operations: two sessions cannot both be inside AlterPropGraph for the same property graph simultaneously, so the check-then-delete race condition Peter identified cannot actually occur.
This is a meaningful clarification: the feared race (two concurrent DROP LABEL sessions each seeing two labels and both proceeding) is already prevented by the existing lock acquisition pattern. No additional locking machinery was needed — just explicit recognition that the existing design already handles it.
Isolation Test Added
To demonstrate the serialization guarantee concretely, Ashutosh added an isolation test that exercises the concurrent DROP LABEL scenario. This is good practice: it documents the expected behavior under concurrency and will catch any future regression if lock levels are inadvertently weakened.
Additional Test Coverage Discussion
Ashutosh raised whether more isolation tests should be added for related scenarios:
- Properties cannot be added to a label being dropped
- Label cannot be added to an element being dropped
- Label cannot be added to an element being added
He asked whether this would be "overkill." No response to this question is visible yet.
Variable Naming
Ashutosh's "Done." likely refers to Peter's ellabelrel naming suggestion being addressed, though this is implicit rather than explicit in the message.
New Patch Version
A new patchset was posted (without the extra tests Ashutosh contemplated), incorporating the isolation test and presumably the variable naming fix.