Re: Violation of principle that plan trees are read-only - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Violation of principle that plan trees are read-only
Date
Msg-id CA+TgmoaubuZ_pn1AWkHQVfMVnPwVZ9NhQY7c7i8j_wqevr_sDg@mail.gmail.com
Whole thread Raw
In response to Violation of principle that plan trees are read-only  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, May 18, 2025 at 7:31 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> While chasing down Valgrind leakage reports, I was disturbed
> to realize that some of them arise from a case where the
> executor scribbles on the plan tree it's given, which it is
> absolutely not supposed to do:
>
>         /*
>          * Initialize result tuple slot and assign its rowtype using the first
>          * RETURNING list.  We assume the rest will look the same.
>          */
>         mtstate->ps.plan->targetlist = (List *) linitial(returningLists);
>
> A bit of git archaeology fingers Andres' commit 4717fdb14, which we
> can't easily revert since he later got rid of ExecAssignResultType
> altogether.  But I think we need to do something about it --- it's
> purest luck that this doesn't cause serious problems in some cases.

Is there some way that we can detect violations of this rule
automatically? I recall that we were recently discussing with Richard
Guo a proposed patch that would have had a similar problem, so it's
evidently not that hard for a committer to either fail to understand
what the rule is or fail to realize that they are violating it.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Aleksander Alekseev
Date:
Subject: Re: Should we optimize the `ORDER BY random() LIMIT x` case?
Next
From: Jim Jones
Date:
Subject: Re: [PoC] XMLCast (SQL/XML X025)