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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Farias de Oliveira <matheusfarias519(at)gmail(dot)com>
Cc: Amit Langote <amitlangote09(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?
Date: 2023-07-14 15:16:50
Message-ID: 3358197.1689347810@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Farias de Oliveira <matheusfarias519(at)gmail(dot)com> writes:
> 3905 elog(ERROR, "invalid perminfoindex %u in RTE with relid %u",
> (gdb) bt
> #0 getRTEPermissionInfo (rteperminfos=0x138a500, rte=0x138a6b0) at parse_relation.c:3905
> #1 0x0000000000676e29 in GetResultRTEPermissionInfo (relinfo=relinfo(at)entry=0x13b8f50, estate=estate(at)entry=0x138ce48)
> at execUtils.c:1412
> #2 0x0000000000677c30 in ExecGetUpdatedCols (relinfo=relinfo(at)entry=0x13b8f50, estate=estate(at)entry=0x138ce48)
> at execUtils.c:1321
> #3 0x0000000000677cd7 in ExecGetAllUpdatedCols (relinfo=relinfo(at)entry=0x13b8f50, estate=estate(at)entry=0x138ce48)
> at execUtils.c:1362
> #4 0x000000000066b9bf in ExecUpdateLockMode (estate=estate(at)entry=0x138ce48, relinfo=relinfo(at)entry=0x13b8f50) at execMain.c:2385
> #5 0x00007f197fb19a8d in update_entity_tuple (resultRelInfo=<optimized out>, resultRelInfo(at)entry=0x13b8f50,
> elemTupleSlot=elemTupleSlot(at)entry=0x13b9730, estate=estate(at)entry=0x138ce48, old_tuple=0x13bae80)
> at src/backend/executor/cypher_set.c:120
> #6 0x00007f197fb1a2ff in process_update_list (node=node(at)entry=0x138d0c8) at src/backend/executor/cypher_set.c:595
> #7 0x00007f197fb1a348 in process_all_tuples (node=node(at)entry=0x138d0c8) at src/backend/executor/cypher_set.c:212
> #8 0x00007f197fb1a455 in exec_cypher_set (node=0x138d0c8) at src/backend/executor/cypher_set.c:641

So apparently, what we have here is a result-relation RTE that has
no permissions info associated. It's not clear to me whether that
is a bug in building the parse tree, or an expectable situation
that GetResultRTEPermissionInfo ought to be coping with. I'm
inclined to bet on the former though, and to guess that AGE is
missing dealing with the new RTEPermissionInfo structs in someplace
or other. I'm afraid that allowing GetResultRTEPermissionInfo to
let this pass without comment would mask actual bugs, so fixing
it at that end doesn't seem attractive.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ivan Panchenko 2023-07-14 15:37:53 Re: Bytea PL/Perl transform
Previous Message Andres Freund 2023-07-14 15:16:26 Re: New WAL record to detect the checkpoint redo location