Re: Properly pathify the union planner

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Properly pathify the union planner
Date: 2024-03-26 22:22:53
Message-ID: CAApHDvqYa_1HcUM4TjzKqXxuZCgFuwMXqQWwXvwR7ZoDiAknJA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 27 Mar 2024 at 06:00, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> SELECT count(*) FROM (
> WITH q1(x) AS (SELECT 1)
> SELECT FROM q1 UNION SELECT FROM q1
> ) qu;
>
> TRAP: failed Assert("lg != NULL"), File: "planner.c", Line: 7941, PID: 1133017

Thanks for finding that.

There's something weird going on with the UNION child subquery's
setOperations field. As far as I understand, and from reading the
existing comments, this should only be set for the top-level union.

Because this field is set, it plans the CTE thinking it's a UNION
child and breaks when it can't find a SortGroupClause for the CTE's
target list item.

I'll keep digging. As far as I see the setOperations field is only set
in transformSetOperationStmt(). I'm guessing we must be doing a
copyObject() somewhere and accidentally picking up the parent's
setOperations.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2024-03-26 22:54:58 Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Previous Message Jacob Champion 2024-03-26 21:52:23 Re: WIP Incremental JSON Parser