Hi, On 2026-09-02 17:33:38 -0400, Andres Freund wrote: > - As mentioned in my last email, nothing protects the graph object against > being altered while rewriteGraphTable() is running, due to AlterPropGraph() > only holding an AccessShareLock. That's bad.
An particularly odd thing about that is that some things in rewriteGraphTable.c actually use a more heavyweight lock level - is_property_associated_with_label() and get_element_property_expr() use RowShareLock. I don't really understand why? There's no comment about that either? There are also unexplained uses of RowShareLock in propgraphcmds.c - why is e.g. pg_attribute opened with RowShareLock? Separately (noticed when searching for RowShareLock uses): Isn't it somewhat of a problem to do a seqscan of PropgraphLabelPropertyRelationId for /* Remove any orphaned pg_propgraph_property entries */ I don't know why that code uses RowShareLock either. Not using AccessShareLock makes sense, afaict the performDeletion() of PropgraphPropertyRelationId done during the scan will recurse to PropgraphLabelPropertyRelationId - avoiding deadlock hazards due to lock upgrades could make sense. But a deletion takes RowExclusive, not RowShare? So what's the point of RowShare? Greetings, Andres Freund
