Content-Type: multipart/alternative;
 boundary="------------XiFLiKmfZJPSHvJCgVGNnWvL"
Message-ID: <a6e6d603-e847-44dc-acd5-879fb4570062@gmail.com>
Date: Sat, 14 Mar 2026 14:00:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pg_plan_advice
To: Robert Haas <robertmhaas@gmail.com>,
 "David G. Johnston" <david.g.johnston@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: 
 <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com>
 <CA+TgmoaCdsuvNn6T6SfQ_0YD2Hh2+hgTXh9fTGHQhPg1zvy2rQ@mail.gmail.com>
 <CAK98qZ1zWzRB0ABG7ULzTeWKRR5C7-FxLqM-6v8wQDiFM+DNAg@mail.gmail.com>
 <CA+Tgmob7ozJAs5SU6bD2RfAt4w_AmsMGz-aaVA6WeLXHkBypOg@mail.gmail.com>
 <CAK98qZ1J42RoAsHnYWGPPmHziZmzmqE=Lp_O6WJ-9aKK2qjikA@mail.gmail.com>
 <CA+TgmoYjcBA6dw3nwiyfDzPXTCrxTZPXDMrc2TrDJcL1cPK6iA@mail.gmail.com>
 <CA+TgmoYru-vxoTKfwjQby30r2OkTXfb18Km_=VLs6qk8Akr0-g@mail.gmail.com>
 <CAKFQuwYxTMx1e1dvVLd5vs8CO2Xe__YRCW0m4v2UErG=5Lu7kQ@mail.gmail.com>
 <CA+TgmoaPH3rOmH1zw8s10Az3TQKRbDnF3dKYZCAFvx_DgFV5_Q@mail.gmail.com>
 <CAKFQuwZ7CRbvmJ60EjvEUJP8X9hWVCHJz8yJZ0-xRpYwL=fugA@mail.gmail.com>
 <CA+TgmoYsG2pAOG4YYWwnGsaL+QfOZopi_m+f_hZqBZ3meNEkjg@mail.gmail.com>
 <CAKFQuwY4i6xXCRHd=ccrFz0sQOfiWRxhobiBrzyK0rzu1-Y33Q@mail.gmail.com>
 <CA+Tgmobbj_TaCsYmr1grJBTRKaFaxFfotXn1T6LSXs9GQ8_Kyw@mail.gmail.com>
 <CA+TgmoZzM2i+p-Rxdphs4qx7sshn-kzxF91ASQ5duOo0dFRXLQ@mail.gmail.com>
Content-Language: en-US
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: 
 <CA+TgmoZzM2i+p-Rxdphs4qx7sshn-kzxF91ASQ5duOo0dFRXLQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/a6e6d603-e847-44dc-acd5-879fb4570062%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------XiFLiKmfZJPSHvJCgVGNnWvL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello Robert,

12.03.2026 19:15, Robert Haas wrote:
> I've now committed the main patch. I think that I'm not likely to get
> too much more feedback on that in this release cycle, and I judge that
> more people will be sad if it doesn't get shipped this cycle than if
> it does. That might turn out to be catastrophically wrong, but if many
> problem reports quickly begin to emerge, it can always be reverted.
> I'm hopeful my testing has been thorough enough to avoid that, but
> there's a big difference between lab-testing and real world usage, so
> we'll see.

I've found a crash inside pgpa_join_path_setup(), reproduced with:
echo "geqo_threshold = 2" >/tmp/extra.config
TEMP_CONFIG=/tmp/extra.config make -s check -C contrib/pg_plan_advice/

Program terminated with signal SIGSEGV, Segmentation fault.
(gdb) bt
#0  0x000070820b96d215 in pgpa_join_path_setup (root=0x5ef5a84682b8, joinrel=0x5ef5a8497f10, outerrel=0x5ef5a8472b48,
     innerrel=0x5ef5a84baeb8, jointype=JOIN_UNIQUE_INNER, extra=0x7fff08823490) at pgpa_planner.c:602
#1  0x00005ef57df9742b in add_paths_to_joinrel (root=0x5ef5a84682b8, joinrel=0x5ef5a8497f10, outerrel=0x5ef5a8472b48,
     innerrel=0x5ef5a84baeb8, jointype=JOIN_UNIQUE_INNER, sjinfo=0x5ef5a8473c00, restrictlist=0x5ef5a8498450) at 
joinpath.c:178
#2  0x00005ef57df9d178 in populate_joinrel_with_paths (root=0x5ef5a84682b8, rel1=0x5ef5a8472b48, rel2=0x5ef5a84731f0,
     joinrel=0x5ef5a8497f10, sjinfo=0x5ef5a8473c00, restrictlist=0x5ef5a8498450) at joinrels.c:1197
#3  0x00005ef57df9c6ab in make_join_rel (root=0x5ef5a84682b8, rel1=0x5ef5a8472b48, rel2=0x5ef5a84731f0) at joinrels.c:774
#4  0x00005ef57df700be in merge_clump (root=0x5ef5a84682b8, clumps=0x5ef5a8497e60, new_clump=0x5ef5a8497eb0, num_gene=2,
     force=false) at geqo_eval.c:259
#5  0x00005ef57df6ff3e in gimme_tree (root=0x5ef5a84682b8, tour=0x5ef5a84ba688, num_gene=2) at geqo_eval.c:198
#6  0x00005ef57df6fe12 in geqo_eval (root=0x5ef5a84682b8, tour=0x5ef5a84ba688, num_gene=2) at geqo_eval.c:101
#7  0x00005ef57df708fa in random_init_pool (root=0x5ef5a84682b8, pool=0x5ef5a84c3988) at geqo_pool.c:108
#8  0x00005ef57df70439 in geqo (root=0x5ef5a84682b8, number_of_rels=2, initial_rels=0x5ef5a84ba1f8) at geqo_main.c:127
#9  0x00005ef57df77aa3 in make_rel_from_joinlist (root=0x5ef5a84682b8, joinlist=0x5ef5a8473b40) at allpaths.c:3902
#10 0x00005ef57df715e2 in make_one_rel (root=0x5ef5a84682b8, joinlist=0x5ef5a8473b40) at allpaths.c:240
#11 0x00005ef57dfbede4 in query_planner (root=0x5ef5a84682b8, qp_callback=0x5ef57dfc5ae9 <standard_qp_callback>,
     qp_extra=0x7fff08823af0) at planmain.c:297
...

Could please look at this?

Best regards,
Alexander
--------------XiFLiKmfZJPSHvJCgVGNnWvL
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hello Robert,<br>
      <br>
      12.03.2026 19:15, Robert Haas wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+TgmoZzM2i+p-Rxdphs4qx7sshn-kzxF91ASQ5duOo0dFRXLQ@mail.gmail.com">
      <pre wrap="" class="moz-quote-pre">I've now committed the main patch. I think that I'm not likely to get
too much more feedback on that in this release cycle, and I judge that
more people will be sad if it doesn't get shipped this cycle than if
it does. That might turn out to be catastrophically wrong, but if many
problem reports quickly begin to emerge, it can always be reverted.
I'm hopeful my testing has been thorough enough to avoid that, but
there's a big difference between lab-testing and real world usage, so
we'll see.
</pre>
    </blockquote>
    <br>
    I've found a crash inside pgpa_join_path_setup(), reproduced with:<br>
    echo "geqo_threshold = 2" &gt;/tmp/extra.config<br>
    TEMP_CONFIG=/tmp/extra.config make -s check -C
    contrib/pg_plan_advice/<br>
    <br>
    Program terminated with signal SIGSEGV, Segmentation fault.<br>
    (gdb) bt<br>
    #0  0x000070820b96d215 in pgpa_join_path_setup (root=0x5ef5a84682b8,
    joinrel=0x5ef5a8497f10, outerrel=0x5ef5a8472b48, <br>
        innerrel=0x5ef5a84baeb8, jointype=JOIN_UNIQUE_INNER,
    extra=0x7fff08823490) at pgpa_planner.c:602<br>
    #1  0x00005ef57df9742b in add_paths_to_joinrel (root=0x5ef5a84682b8,
    joinrel=0x5ef5a8497f10, outerrel=0x5ef5a8472b48, <br>
        innerrel=0x5ef5a84baeb8, jointype=JOIN_UNIQUE_INNER,
    sjinfo=0x5ef5a8473c00, restrictlist=0x5ef5a8498450) at
    joinpath.c:178<br>
    #2  0x00005ef57df9d178 in populate_joinrel_with_paths
    (root=0x5ef5a84682b8, rel1=0x5ef5a8472b48, rel2=0x5ef5a84731f0, <br>
        joinrel=0x5ef5a8497f10, sjinfo=0x5ef5a8473c00,
    restrictlist=0x5ef5a8498450) at joinrels.c:1197<br>
    #3  0x00005ef57df9c6ab in make_join_rel (root=0x5ef5a84682b8,
    rel1=0x5ef5a8472b48, rel2=0x5ef5a84731f0) at joinrels.c:774<br>
    #4  0x00005ef57df700be in merge_clump (root=0x5ef5a84682b8,
    clumps=0x5ef5a8497e60, new_clump=0x5ef5a8497eb0, num_gene=2, <br>
        force=false) at geqo_eval.c:259<br>
    #5  0x00005ef57df6ff3e in gimme_tree (root=0x5ef5a84682b8,
    tour=0x5ef5a84ba688, num_gene=2) at geqo_eval.c:198<br>
    #6  0x00005ef57df6fe12 in geqo_eval (root=0x5ef5a84682b8,
    tour=0x5ef5a84ba688, num_gene=2) at geqo_eval.c:101<br>
    #7  0x00005ef57df708fa in random_init_pool (root=0x5ef5a84682b8,
    pool=0x5ef5a84c3988) at geqo_pool.c:108<br>
    #8  0x00005ef57df70439 in geqo (root=0x5ef5a84682b8,
    number_of_rels=2, initial_rels=0x5ef5a84ba1f8) at geqo_main.c:127<br>
    #9  0x00005ef57df77aa3 in make_rel_from_joinlist
    (root=0x5ef5a84682b8, joinlist=0x5ef5a8473b40) at allpaths.c:3902<br>
    #10 0x00005ef57df715e2 in make_one_rel (root=0x5ef5a84682b8,
    joinlist=0x5ef5a8473b40) at allpaths.c:240<br>
    #11 0x00005ef57dfbede4 in query_planner (root=0x5ef5a84682b8,
    qp_callback=0x5ef57dfc5ae9 &lt;standard_qp_callback&gt;, <br>
        qp_extra=0x7fff08823af0) at planmain.c:297<br>
    ...<br>
    <br>
    Could please look at this?<br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------XiFLiKmfZJPSHvJCgVGNnWvL--