From: Tom Lane <tgl@sss.pgh.pa.us>
To: Amit Langote <amitlangote09@gmail.com>
cc: Hans Buschmann <buschmann@nidsa.net>, 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: 
 <CA+HiwqFmOaOWXW=KNFGfHRaXME50SqZa__GvsWjaWVXSFyY0kw@mail.gmail.com>
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>
 <408285.1698085850@sss.pgh.pa.us> <428393.1698094765@sss.pgh.pa.us>
 <CA+HiwqHEdX7SSTLJw0=F3nU_BRyn2tUsw7A-cQs+=M_RL0czSw@mail.gmail.com>
 <556852.1698158932@sss.pgh.pa.us> <839708.1698174464@sss.pgh.pa.us>
 <CA+HiwqFmOaOWXW=KNFGfHRaXME50SqZa__GvsWjaWVXSFyY0kw@mail.gmail.com>
Comments: In-reply-to Amit Langote <amitlangote09@gmail.com>
	message dated "Wed, 25 Oct 2023 17:16:22 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <967240.1698241891.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Wed, 25 Oct 2023 09:51:31 -0400
Message-ID: <967241.1698241891@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/967241.1698241891%40sss.pgh.pa.us>
Precedence: bulk

Amit Langote <amitlangote09@gmail.com> writes:
> On Wed, Oct 25, 2023 at 4:07 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I suspect that now this should just unconditionally clear
>> childrte->perminfoindex, but it's minor cleanup not a bug fix
>> so I didn't pursue that in the initial patch.

> Would you like me to apply something like the attached?

Diff looks fine, but I'm not sure that it's appropriate to characterize
the existing code as an oversight.  It was a necessary hack while the
executor was behaving as it did (ie, using the first child as root).

>> * It seems like ModifyTable.nominalRelation and
>> ModifyTable.rootRelation are pretty darn redundant.  Maybe we
>> should make an effort to get rid of one of them.  Or maybe
>> it's not worth the trouble.

> We had a discussion on unifying the two before:
> https://www.postgresql.org/message-id/12148.1538938507%40sss.pgh.pa.us

Ah, so we did.  The "serve different masters" argument did re-occur
to me while I was looking at this yesterday, but I'm not sure how
strong it is really.  Anyway, I'm also content to leave it be.

			regards, tom lane