(SQL/PGQ) cache lookup failed for label

First seen: 2026-05-08 08:39:46+00:00 · Messages: 14 · Participants: 4

Latest Update

2026-06-04 · claude-opus-4-6

Monthly Summary: (SQL/PGQ) cache lookup failed for label — May 2026

Overview

A dependency-tracking bug in PostgreSQL's SQL/PGQ (Property Graph Queries) implementation was reported, diagnosed, patched, reviewed through multiple iterations, and brought to "Ready for Committer" status within the month. The bug allowed ALTER PROPERTY GRAPH ... DROP LABEL to succeed even when views referenced the label, causing subsequent cache lookup failed for label <OID> errors. The root cause was that find_expr_references_walker in dependency.c never descended into graph-specific node types (GraphLabelRef, GraphPropertyRef), so no pg_depend rows were ever recorded connecting views to label/property objects.

Key Developments

Bug Diagnosis and Initial Patch (Zeng Man)

The original reporter demonstrated the issue: creating a view over GRAPH_TABLE(... MATCH (a IS l2) ...), then dropping label l2 via ALTER PROPERTY GRAPH, then getting cache lookup failed on view access. The initial patch added handlers for GraphLabelRef and GraphPropertyRef in find_expr_references_walker and manually iterated through RTE_GRAPH_TABLE's graph_pattern substructure.

Reviewer Feedback (Ashutosh Bapat)

Bapat identified several issues with the original approach:

Handoff and Architectural Simplification (Ayush Tiwari)

Zeng Man stepped back due to time constraints. Ayush Tiwari took over with a cleaner approach: since query_tree_walker() already descends into rte->graph_pattern and rte->graph_table_columns, only leaf-node handlers for GraphLabelRef and GraphPropertyRef are needed — no manual iteration required. This went through v1→v3 with incremental test improvements.

Committer-Level Revision (Ashutosh Bapat)

Bapat posted a near-final revision with:

Approval and Status

Both Junwang Zhao and Ayush Tiwari gave LGTM on Bapat's revision. The Commitfest entry was marked "Ready for Committer."

Deeper Issues Identified (Not Blocking)

Bapat identified two additional architectural problems to address separately:

  1. Empty label expansion timing: Currently happens at rewrite phase but should move to transform (parse analysis) so that resolved labels get pg_depend rows and are captured in catalog/dump representations
  2. Label removal edge cases: Dropping a label from vertex tables (but not edge tables) produces obscure errors rather than clear dependency violations; may require making vertex/edge labels separate catalog objects

Current Status

The dependency-tracking fix is ready to commit. The deeper architectural issues (empty label expansion timing, vertex/edge label distinction) will be addressed in follow-up patches once the approach is decided.

History (1 prior analysis)
2026-06-04 · claude-opus-4-6

Bapat Posts Patch Series (0005-0007) Implementing All Three Fixes

Ashutosh Bapat has posted the actual patches implementing the fixes he previously described. The key new technical decisions and content:

Patch 0005: Cache Lookup Fix (Previously Discussed, Now Finalized)

This is the original dependency-tracking fix for cache lookup failed for label, now in its final committed form as part of the series.

Patch 0006: Empty Label Expression Resolution Moved to Transform Phase

This is the substantive new work. Key design decisions:

  1. Empty label expressions that resolve to no labels are now prohibited — treated as an unsupported feature. Bapat doubts there's a valid use case for a label expression that matches nothing. This is a forward-looking constraint that prevents pathological cases.

  2. Rationale for fixing now rather than deferring: Bapat explicitly argues this cannot wait until the "all-properties reference" (*) feature is implemented because:

    • Without the fix, queries with empty label expressions silently return different results as labels are added/removed from the property graph
    • When all-properties support is added later, the behavior would have to change, breaking backward compatibility
    • Fixing now establishes correct semantics before users rely on the current (broken) behavior

  3. Existing test breakage addressed: A test in create_property_graph.sql that used an empty property graph for testing view-to-graph dependencies broke because empty label expressions on an empty graph now error out. Fixed by adding a vertex table to the referenced property graph.

  4. Behavioral test included but optional: Bapat added a test case demonstrating the current behavior around empty label expressions, but explicitly says he's fine either way on committing it — it serves as documentation for future developers but isn't strictly necessary.

Patch 0007: Label Sharing Between Vertex and Edge Tables

This addresses the asymmetry issue where a label exists on both vertex and edge tables, and removing it from one type can silently break views. No specific implementation details are visible beyond it being a separate patch in the series.

Patch Series Structure

Bapat notes patches are numbered 0005-0007 because they come from a branch with other outstanding SQL/PGQ fixes (patches 0001-0004 presumably from the related thread he previously referenced). They apply cleanly to latest master with git am.

Commit Message Strategy

The commit message for patch 0006 intentionally keeps things simple — mentioning only the label dependency asymmetry between explicit and empty label expressions, without diving into the all-properties-reference complexity. The mailing list discussion link serves as the detailed reference.