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
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 |