Re: Assert failure in try_nestloop_path() - Mailing list pgsql-hackers

From Richard Guo
Subject Re: Assert failure in try_nestloop_path()
Date
Msg-id CAMbWs4_KT4LGcxS4oyoHsTTfTdw_evJ0DdWcaejDi9hbSp0dXg@mail.gmail.com
Whole thread
In response to Re: Assert failure in try_nestloop_path()  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-hackers
On Sun, Sep 27, 2026 at 1:00 AM Alexander Lakhin <exclusion@gmail.com> wrote:
> I've discovered that:
> echo "geqo_threshold = 2" >/tmp/temp.config
> TEMP_CONFIG=/tmp/temp.config TESTS="partition_join" make -s check-tests
>
> triggers one of the assertions:
> TRAP: failed Assert("no_duplicate_clause_serials(*restrict_clauses)"), File: "relnode.c", Line: 2079, PID: 634394

Thanks for the report.  I think the culprit is that during GEQO join
planning, add_child_join_rel_equivalences() will re-add the same child
EC members in each GEQO round, since it has no concept that the
members it wants might be there already.  As a result, in the reported
case, the same EC member PHV(COALESCE(t3_p1.c, t4.c)) appears three
times in the same EC.  So, in get_joinrel_parampathinfo(), the
generate_join_implied_equalities() call generate two identical
RestrictInfos for "PHV(...) = PHV(...)".

I think we need to do something to avoid generating duplicate EC
members in add_child_join_rel_equivalences().

- Richard



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: ReplicationSlotRelease() clobbers another backend's statusFlags entry
Next
From: Daniel Gustafsson
Date:
Subject: Re: Stabilize and shorten test_checksums/013_rewind test