Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1quzhb-002Uxd-B7
	for pgsql-bugs@arkaria.postgresql.org; Mon, 23 Oct 2023 18:30:59 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.94.2)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1quzhZ-00DWFV-09
	for pgsql-bugs@arkaria.postgresql.org; Mon, 23 Oct 2023 18:30:57 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1quzhY-00DWF3-Nw
	for pgsql-bugs@lists.postgresql.org; Mon, 23 Oct 2023 18:30:57 +0000
Received: from sss.pgh.pa.us ([68.162.161.243])
	by magus.postgresql.org with esmtps  (TLS1.3) tls
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	(Exim 4.94.2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1quzhW-002JX2-F5
	for pgsql-bugs@lists.postgresql.org; Mon, 23 Oct 2023 18:30:56 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 39NIUoms408286;
	Mon, 23 Oct 2023 14:30:50 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Hans Buschmann <buschmann@nidsa.net>
cc: Amit Langote <amitlangote09@gmail.com>, Peter Geoghegan <pg@bowt.ie>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Subject: Re: AW: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with
 relid xxxxx
In-reply-to: <3c9fe737f6aa4ae9b0dc19bffd97e106@nidsa.net>
References: <18147-6fc796538913ee88@postgresql.org>
 <CAKFQuwYFq-Q2rxbXXBmdHCAEFm-Pu_qhPAEi-PO+LmjtYN2hhg@mail.gmail.com>,<2796464.1696525626@sss.pgh.pa.us>
 <9fdfed847859435e8641e613198be9e3@nidsa.net>,<3319880.1696778678@sss.pgh.pa.us>
 <3c9fe737f6aa4ae9b0dc19bffd97e106@nidsa.net>
Comments: In-reply-to Hans Buschmann <buschmann@nidsa.net>
	message dated "Mon, 23 Oct 2023 17:05:03 -0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <408284.1698085850.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 23 Oct 2023 14:30:50 -0400
Message-ID: <408285.1698085850@sss.pgh.pa.us>
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Archived-At: 
 <https://www.postgresql.org/message-id/408285.1698085850%40sss.pgh.pa.us>
Precedence: bulk

Hans Buschmann <buschmann@nidsa.net> writes:
> I finally managed to reproduce the bug on a demo database as shown below=
.

Thanks!  Reproduced it as described on HEAD (although for me, repeating
the query repeats the error, there's no need to do anything fancy to
re-arm it).  Backtrace looks like

#0  errfinish (filename=3D0xaad704 "parse_relation.c", lineno=3D3907, =

    funcname=3D0xaae690 <__func__.24632> "getRTEPermissionInfo") at elog.c=
:480
#1  0x00000000004b07fa in getRTEPermissionInfo (rteperminfos=3D<optimized =
out>, =

    rte=3D0x1725ba8) at parse_relation.c:3906
#2  0x00000000006d6345 in GetResultRTEPermissionInfo (
    estate=3Destate@entry=3D0x1739120, relinfo=3D<optimized out>, =

    relinfo=3D<optimized out>) at execUtils.c:1386
#3  0x00000000006d755c in ExecGetUpdatedCols (relinfo=3Drelinfo@entry=3D0x=
17395e0, =

    estate=3Destate@entry=3D0x1739120) at execUtils.c:1295
#4  0x00000000006c8292 in index_unchanged_by_update (indexRelation=3D0x177=
2770, =

    indexInfo=3D0x17ea4a0, estate=3D0x1739120, resultRelInfo=3D0x17395e0)
    at execIndexing.c:985
#5  ExecInsertIndexTuples (resultRelInfo=3DresultRelInfo@entry=3D0x17395e0=
, =

    slot=3Dslot@entry=3D0x17ea140, estate=3D0x1739120, update=3Dupdate@ent=
ry=3Dtrue, =

    noDupErr=3DnoDupErr@entry=3Dfalse, specConflict=3DspecConflict@entry=3D=
0x0, =

    arbiterIndexes=3D0x0, onlySummarizing=3Dfalse) at execIndexing.c:427
#6  0x00000000006f560a in ExecUpdateEpilogue (
    resultRelInfo=3DresultRelInfo@entry=3D0x17395e0, =

    tupleid=3Dtupleid@entry=3D0x7ffd1fa2b10e, oldtuple=3Doldtuple@entry=3D=
0x0, =

    slot=3D0x17ea140, updateCxt=3D<optimized out>, context=3D<optimized ou=
t>, =

    context=3D<optimized out>) at nodeModifyTable.c:2130
#7  0x00000000006f6b24 in ExecUpdate (context=3D0x7ffd1fa2b140, =

    resultRelInfo=3D0x17395e0, tupleid=3D0x7ffd1fa2b10e, oldtuple=3D0x0, =

    slot=3D0x17ea140, canSetTag=3D<optimized out>) at nodeModifyTable.c:24=
78
#8  0x00000000006f834b in ExecModifyTable (pstate=3D<optimized out>)
    at nodeModifyTable.c:3824

In ExecGetUpdatedCols,

(gdb) p relinfo->ri_RootResultRelInfo
$2 =3D (struct ResultRelInfo *) 0x0
(gdb) p relinfo->ri_RangeTableIndex
$3 =3D 5

RTE 5 is the added-on RTE for the child table or_followup_archiv.
It looks like

      {RANGETBLENTRY =

      :alias =

         {ALIAS =

         :aliasname or_followup =

         :colnames ("id_of" "of_season" "of_pr1_fac_netto" "of_pr1_fac_net=
usd"
          "of_pr2_fac_netto" "of_pr2_fac_netusd" "of_pr1_our_netto" "of_pr=
1_ou
         r_netusd" "of_pr2_our_netto" "of_pr2_our_netusd")
         }
      :eref =

         {ALIAS =

         :aliasname or_followup =

         :colnames ("id_of" "of_season" "of_pr1_fac_netto" "of_pr1_fac_net=
usd"
          "of_pr2_fac_netto" "of_pr2_fac_netusd" "of_pr1_our_netto" "of_pr=
1_ou
         r_netusd" "of_pr2_our_netto" "of_pr2_our_netusd")
         }
      :rtekind 0 =

      :relid 41352 	or_followup_archiv
      :relkind r =

      :rellockmode 3 =

      :tablesample <> =

      :perminfoindex 0 =

      :lateral false =

      :inh false =

      :inFromCl false =

      :securityQuals <>
      }

So the proximate problem is that we're trying to fetch an updatedCols
bitmapset for a child table that has no permissions checks to make
and thus doesn't need an RTEPermissionInfo, so its perminfoindex is
zero.  It might be that this relinfo should have ri_RootResultRelInfo
set, but it doesn't.  It's also possible that we erred by taking those
bitmapsets out of RTEs, although that'd be an unpleasant conclusion
with v16 already released.

However ... the need to fetch that data is ultimately coming from
index_unchanged_by_update, and I don't see how that is not buggy
as can be, independently of this.  How can it be okay to ignore
the effects of BEFORE triggers when deciding if an index is unchanged?
If this is because it's "only a hint" and doesn't have to be reliable,
okay, but the documentation around indexUnchanged utterly fails to
make that clear.  I fear some poor index AM writer is going to get
screwed big time when they assume this flag is good for more than
heuristic decisions about when to do noncritical maintenance.

The reason I'm on about that is that if it's okay for
index_unchanged_by_update to lie, another approach we could consider
is to return a default result if we're looking at a child table
for which we lack updatedCols data.  We might have to do that in
v16, since we don't have much wiggle room to adjust the
RTEPermissionInfo data in a released branch.

(I haven't looked into exactly why it's so hard to reach this
error.  Seems like any inherited UPDATE is at risk, so there
must be additional gating factors to explain why we've not
noticed this before.)

			regards, tom lane