Re: Core dump in range_table_mutator()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Core dump in range_table_mutator()
Date: 2022-06-26 13:06:11
Message-ID: 1349484.1656248771@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Sat, 25 Jun 2022 at 04:39, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Well, if we want to clean this up a bit rather than just doing the
>> minimum safe fix ... I spent some time why we were bothering with the
>> FLATCOPY step at all, rather than just mutating the Query* pointer.
>> I think the reason is to not fail if the QTW_DONT_COPY_QUERY flag is
>> set, but maybe we should clear that flag when recursing?

> Hmm, interesting, but we don't actually pass on that flag when
> recursing anyway. Since it is the mutator routine's responsibility to
> make a possibly-modified copy of its input node, if it wants to
> recurse into the subquery, it should always call query_tree_mutator()
> with QTW_DONT_COPY_QUERY unset, and range_table_mutator() should never
> need to FLATCOPY() the subquery.

Actually, QTW_DONT_COPY_QUERY is dead code AFAICS: we don't use it
anywhere, and Debian Code Search doesn't know of any outside users
either. Removing it might be something to do in v16. (I think
it's a bit late for unnecessary API changes in v15.)

> But then, in the interests of further tidying up, why does
> range_table_mutator() call copyObject() on the subquery if
> QTW_IGNORE_RT_SUBQUERIES is set?

I thought about that for a bit, but all of the QTW_IGNORE flags
work like that, and I'm hesitant to change it. There may be
code that assumes it can modify those trees in-place afterwards.

Committed with just the change to use straight MUTATE, making
this case exactly like the other places with QTW_IGNORE options.
Thanks for the discussion!

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2022-06-26 15:44:22 JSON/SQL: jsonpath: incomprehensible error message
Previous Message Michael Paquier 2022-06-26 07:20:34 Re: ICU for global collation