Re: BUG #18902: TRAP:: failed Assert("!is_sorted") in File: "createplan.c"

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tender Wang <tndrwang(at)gmail(dot)com>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, n(dot)kalinin(at)postgrespro(dot)ru, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18902: TRAP:: failed Assert("!is_sorted") in File: "createplan.c"
Date: 2025-05-08 10:26:30
Message-ID: CAMbWs4_BgQV=LXxddUzNgq1A1zKJLdrKdViyMkngobWgRm8XAg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, May 3, 2025 at 10:50 AM Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> Richard Guo <guofenglinux(at)gmail(dot)com> 于2025年5月2日周五 15:03写道:
>> Fair point. Here is the patchset doing that. 0001 fixes this bug by
>> setting outersortkeys/innersortkeys to NIL in GetExistingLocalJoinPath
>> if we detect that the new outer/inner path of the MergePath is already
>> sorted properly.

> The 0001 fixing this bug looks good to me.

I've pushed this fix to master. I'm not quite sure whether it should
be backpatched. In the back branches, the issue leads to the addition
of a redundant Sort node in the plan that is only used for EPQ checks.
Since usually the efficiency of the EPQ plan is not a concern, this
doesn't seem like a big issue. Besides, this issue has existed in
back branches for a long time but we haven't received any field
reports.

That said, if anyone thinks there's a good reason to backpatch it, I'm
happy to do so.

Thanks
Richard

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2025-05-08 10:28:38 Re: BUG #18902: TRAP:: failed Assert("!is_sorted") in File: "createplan.c"
Previous Message Tom Lane 2025-05-08 01:50:34 Re: BUG #18917: "Foreign key constraint drop fails with 'column is not in index' unless pg_constraint is queried