Thanks Amit and Tom for the quick response. I have attached a file that contains the execution of the code via GDB and also what the backtrace command shows when it gets the error. If I forgot to add something or if it is necessary to add anything else, please let me know.
On Fri, Jul 14, 2023 at 7:12 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Farias de Oliveira <matheusfarias519@gmail.com> writes: > > With further inspection in AGE's code, after executing the SET query, > > it goes inside transform_cypher_clause_as_subquery() function and the > > ParseNamespaceItem has the following values: > > > {p_names = 0x1205638, p_rte = 0x11edb70, p_rtindex = 1, p_perminfo = > > 0x7f7f7f7f7f7f7f7f, > > p_nscolumns = 0x1205848, p_rel_visible = true, p_cols_visible = > > true, p_lateral_only = false, > > p_lateral_ok = true} > > Hmm, that uninitialized value for p_perminfo is pretty suspicious. > I see that transformFromClauseItem and buildNSItemFromLists both > create ParseNamespaceItems without bothering to fill p_perminfo, > while buildNSItemFromTupleDesc fills it per the caller and > addRangeTableEntryForJoin always sets it to NULL. I think we > ought to make the first two set it to NULL as well, because > uninitialized fields are invariably a bad idea (even though the > lack of valgrind complaints says that the core code is managing > to avoid touching those fields).
Agreed, I'll go ahead and fix that.
> If we do that, is it sufficient to resolve your problem?
Hmm, I'm afraid maybe not, because if the above were the root issue, we'd have seen a segfault and not the error the OP mentioned? I'm thinking the issue is that their code appears to be consing up an RTE that the core code (getRTEPermissionInfo() most likely via markRTEForSelectPriv()) is not expecting to be called with? I would be helpful to see a backtrace when the error occurs to be sure.
