Hi,
On 2026-09-02 15:29:06 -0400, Melanie Plageman wrote:
> Whether there should be a pg_class entry for property graphs:
> ---
> Andres who posted his initial concern about this has not indicated if
> the answers resolve his concern.
It does. I was really just curious why that choice was made. And I think
Ashutosh's answer explains it and I think alternative ways of implementing the
single-namespace would be way worse. Other than perhaps immortalizing it in a
comment somewhere, not further action is needed.
> Separately, though having a pg_class entry seems to buy you some
> functionality for free, the bug Andrew reported where AlterPropGraph()
> doesn't verify its target is a property graph feels like it may be
> indicative of more problems related to code that is reading pg_class entries
> and not distinguishing between graphs and tables.
I think that's a serious bug, but it's also pretty easy to fix, and it's
something that a lot of different places already have to have checks
for. Needing to check for a specific relkind is far from unique to propgraphs.
To me the concerning aspect about that omission isn't so much that it
indicates an architectural issue, but that it pretty clearly indicates
insufficiently reviewed code.
I was looking at AlterPropGraph() while writing the above paragraphs, and it
made me wonder why it'd be sufficient to use ShareRowExclusiveLock? Why is it
ok to alter a propgraph fairly fundamentally while there's queries using the
propgraph (with AccessShareLock, which does not conflict with
ShareRowExclusiveLock)? It's obviously sometimes possible to use
ShareRowExclusiveLock, but typically not for stuff that could completely
invalidate concurrently running queries, and changing the schema of a
propgraph by dropping vertex/edges certainly seems like it would?
Greetings,
Andres Freund
