Re: BUG #18170: Unexpected error: no relation entry for relid 3

On 27/10/2023 16:07, Andrei Lepikhov wrote:
> On 27/10/2023 15:17, Alexander Korotkov wrote:
>> On Fri, Oct 27, 2023 at 9:31 AM Andrei Lepikhov
>> <a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
>>> On 27/10/2023 00:12, Tom Lane wrote:
>>>> Vik Fearing <vik(at)postgresfriends(dot)org> writes:
>>>>> On 10/26/23 16:01, PG Bug reporting form wrote:
>>>>>> My fuzzer finds a bug in Postgres, which triggers an unexpected
>>>>>> error.
>>>>
>>>>> This bisects to d3d55ce571369dad6e1d582f1655e5a3fbd8594a, Remove
>>>>> useless
>>>>> self-joins.
>>>>
>>>> I wonder if that new code thinks it can remove ref_2 from the query,
>>>> even though ref_2 is used in the targetlist.  I'm not seeing
>>>> control reach remove_leftjoinrel_from_query, though.
>>>
>>> As I see, this join can be removed: in the explain you can see that
>>> OUTER JOIN is replaced with the INNER JOIN(ref_2, ref_3) ON a key
>>> column.
>>> In my opinion, the origin of the problem is that the parent_root
>>> contains a link to ref_2 in its
>>> simple_rte_array[]->subquery->targetList. I am still looking for a
>>> general solution right now, but it doesn't look too complicated at first
>>> sight.
>>
>> Yes, I came to the same conclusion.  We process root->parse.  But I
>> didn't get why parent_root->simple_rte_array[]->subquery is not the
>> same as root->parse.  They look the same, but they are distinct
>> copies.  If they were the same pointers, there would be no problem.
>
> As I see, the copy of the parse tree is induced by the same feature as
> usual in the last few months: 2489d76. It introduced
> remove_nulling_relids, and it altered our parse tree. Right now, I don't
> have an answer: it should be fixed in SJE, or this is a more general
> issue just discovered by the SJE.

So, I can propose two options. First - don't clean only the current root
structure, but also make cleanup of the parent. Although it looks safe,
I am not happy with this approach - it seems too simple: we should have
a genuine reason for such a cleaning because it potentially adds overhead.
The second option is to add a flag for not altering queries in
remove_nulling_relids() - it looks like a mistake when we have two
different query trees in the root and its parent. Also, it reduces
memory usage a bit.
So, if my analysis is correct, it is better to use the second way (see
attachment).

--
regards,
Andrei Lepikhov
Postgres Professional