Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?

Hello,

Thank you Amit, changing the 3rd argument to 0 fixes some of the errors
(there are 6 out of 24 errors still failing) but it throws a new one
"ERROR: bad buffer ID: 0". We will need to take a more in depth look here
on why this is occuring, but thank you so much for the help.

Thank you,
Matheus Farias

Em qua., 26 de jul. de 2023 às 08:30, Amit Langote <amitlangote09(at)gmail(dot)com>
escreveu:

> Hello,
>
> On Fri, Jul 21, 2023 at 5:05 AM Farias de Oliveira
> <matheusfarias519(at)gmail(dot)com> wrote:
> >
> > Hello,
> >
> > Thank you for the help guys and I'm so sorry for my late response.
> Indeed, the error relies on the ResultRelInfo. In
> GetResultRTEPermissionInfo() function, it does a checking on the
> relinfo->ri_RootResultRelInfo variable. I believe that it should go inside
> this scope:
> >
> >
> > if (relinfo->ri_RootResultRelInfo)
> > {
> > /*
> > * For inheritance child result relations (a partition routing target
> > * of an INSERT or a child UPDATE target), this returns the root
> > * parent's RTE to fetch the RTEPermissionInfo because that's the only
> > * one that has one assigned.
> > */
> > rti = relinfo->ri_RootResultRelInfo->ri_RangeTableIndex;
> > }
> >
> > The relinfo contains:
> >
> > {type = T_ResultRelInfo, ri_RangeTableIndex = 5, ri_RelationDesc =
> 0x7f44e3308cc8, ri_NumIndices = 0, ri_IndexRelationDescs = 0x0,
> ri_IndexRelationInfo = 0x0, ri_RowIdAttNo = 0,
> > ri_extraUpdatedCols = 0x0, ri_projectNew = 0x0, ri_newTupleSlot = 0x0,
> ri_oldTupleSlot = 0x0, ri_projectNewInfoValid = false, ri_TrigDesc = 0x0,
> ri_TrigFunctions = 0x0,
> > ri_TrigWhenExprs = 0x0, ri_TrigInstrument = 0x0, ri_ReturningSlot =
> 0x0, ri_TrigOldSlot = 0x0, ri_TrigNewSlot = 0x0, ri_FdwRoutine = 0x0,
> ri_FdwState = 0x0,
> > ri_usesFdwDirectModify = false, ri_NumSlots = 0,
> ri_NumSlotsInitialized = 0, ri_BatchSize = 0, ri_Slots = 0x0, ri_PlanSlots
> = 0x0, ri_WithCheckOptions = 0x0,
> > ri_WithCheckOptionExprs = 0x0, ri_ConstraintExprs = 0x0,
> ri_GeneratedExprsI = 0x0, ri_GeneratedExprsU = 0x0, ri_NumGeneratedNeededI
> = 0, ri_NumGeneratedNeededU = 0,
> > ri_returningList = 0x0, ri_projectReturning = 0x0,
> ri_onConflictArbiterIndexes = 0x0, ri_onConflict = 0x0,
> ri_matchedMergeAction = 0x0, ri_notMatchedMergeAction = 0x0,
> > ri_PartitionCheckExpr = 0x0, ri_ChildToRootMap = 0x0,
> ri_ChildToRootMapValid = false, ri_RootToChildMap = 0x0,
> ri_RootToChildMapValid = false, ri_RootResultRelInfo = 0x0,
> > ri_PartitionTupleSlot = 0x0, ri_CopyMultiInsertBuffer = 0x0,
> ri_ancestorResultRels = 0x0}
> >
> > Since relinfo->ri_RootResultRelInfo = 0x0, the rti will have no value
> and Postgres will interpret that the ResultRelInfo must've been created
> only for filtering triggers and the relation is not being inserted into.
> > The relinfo variable is created with the create_entity_result_rel_info()
> function:
> >
> > ResultRelInfo *create_entity_result_rel_info(EState *estate, char
> *graph_name,
> > char *label_name)
> > {
> > RangeVar *rv;
> > Relation label_relation;
> > ResultRelInfo *resultRelInfo;
> >
> > ParseState *pstate = make_parsestate(NULL);
> >
> > resultRelInfo = palloc(sizeof(ResultRelInfo));
> >
> > if (strlen(label_name) == 0)
> > {
> > rv = makeRangeVar(graph_name, AG_DEFAULT_LABEL_VERTEX, -1);
> > }
> > else
> > {
> > rv = makeRangeVar(graph_name, label_name, -1);
> > }
> >
> > label_relation = parserOpenTable(pstate, rv, RowExclusiveLock);
> >
> > // initialize the resultRelInfo
> > InitResultRelInfo(resultRelInfo, label_relation,
> > list_length(estate->es_range_table), NULL,
> > estate->es_instrument);
> >
> > // open the parse state
> > ExecOpenIndices(resultRelInfo, false);
> >
> > free_parsestate(pstate);
> >
> > return resultRelInfo;
> > }
> >
> > In this case, how can we get the relinfo->ri_RootResultRelInfo to store
> the appropriate data?
>
> Your function doesn't seem to have access to the ModifyTableState
> node, so setting ri_RootResultRelInfo to the correct ResultRelInfo
> node does not seem doable.
>
> As I suggested in my previous reply, please check if passing 0 (not
> list_length(estate->es_range_table)) for the 3rd argument
> InitResultRelInfo() fixes the problem and gives the correct result.
>
> --
> Thanks, Amit Langote
> EDB: http://www.enterprisedb.com
>