Hi, On 2026-09-02 15:29:06 -0400, Melanie Plageman wrote: > [RMT hat] > > The RMT has been spending time looking at the current state of PGQ > given the release time, and we have some serious concerns about the > number of design issues with either recently posted patches or without > consensus on behavior. The majority of those are in this thread, so > I'll summarize my understanding of a few of them that are currently > unresolved:
I concur, this isn't ready for v19. And I think it might not be ready to stay in 20 either. Observations from looking at the relevant code for about half the time since my last email: - Afaict the locking in rewriteGraphTable() is wrong. Unless I am missing something, we're accessing the schema of the referenced tables without holding any locks on the tables (c.f. get_atttypetypmodcoll() calls in build_edge_vertex_link_quals()) This isn't just bad when the graph table query is in a view (where the parser wouldn't have acquired locks), afaict parse-analysis doesn't acquire any locks on the element tables? - 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. - Also bad: Afaict a table or column - involved in a property graph - being dropped, does not seem to actually lock the property graph? Which means that could happen concurrently with rewriteGraphTable() even if AlterPropGraph() - The code doesn't seem to follow postgres' coding style much. E.g. there are a lot of very long lines without there being any reason for that. This is a partial manual review, for less than 40min, looking just at one aspect. And I am pretty sure at least some of the above is valid. There's bound to me more. I think this feature is nowhere near ready. Greetings, Andres Freund
