Re: Assert failure in try_nestloop_path()

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Tender Wang <tndrwang(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Assert failure in try_nestloop_path()
Date: 2026-09-10 01:36:46
Message-ID: CAMbWs4-9-FrN1t+3gi5=UeNhNyhhx9T+Aj8TDJkUQCGbw7y34Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 9, 2026 at 11:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The one nit I can find to pick with this is that I don't really like
> the description of the clauses of concern as "textually identical".
> That makes it sound like surface syntax details (like number of
> spaces or presence of an unnecessary table qualifier) matter.
> Perhaps say "parse-tree identical", or "equal()"? That seems a bit
> jargony but I have no better ideas.

Agreed, I've switched to "parse-tree identical" in both the comment
and the commit message.

> I wonder if we are going to push the rinfo_serial mechanism too far.
> But that's just a vague feeling of discomfort, I can't say there is
> anything wrong with fixing it this way.

Right, I have a similar feeling. It seems that rinfo_serial is
becoming more and more load-bearing as a general "this is the same
condition" key. But I couldn't find a better solution, and it's
already what create_nestloop_path relies on to drop conditions that
are due to be moved into the inner path. Maybe this is something we
need to revisit in the future when we have a better mechanism.

> I wonder if we should leave the Assert bits out of v19. The intent to
> have hard prevention of duplicate clauses is a brand new aspiration,
> and I have pretty much no faith that no such cases remain. I don't
> really want to commit to fixing all such cases in v19.

Fair point. I kept the assertions on HEAD only, with a note in the
commit message.

I've pushed both to master and v19.

- Richard

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Jinqing Kuang 2026-09-10 01:35:27 Re: postgres_fdw: push down FETCH FIRST .. WITH TIES when server version allows