Re: PGQ catalog representation and pg_dump support

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