Re: Implement missing join selectivity estimation for range types

On Fri, Sep 18, 2026 at 1:19 PM Bryan Green <dbryan(dot)green(at)gmail(dot)com> wrote:
>
> On 4/24/2026 1:44 PM, Haibo Yan wrote:
> > On Thu, Apr 23, 2026 at 5:32 AM SCHOEMANS Maxime <maxime(dot)schoemans(at)ulb(dot)be>
> > wrote:
> >
> >> Hi Haibo,
> >>
> >> Thanks for creating the CommitFest entry. Could you add Diogo Repas,
> >> Zhicheng Luo, and Mahmoud Sakr as authors as well? They wrote the
> >> original patch and the underlying algorithm. The earlier CF entry is
> >> at https://commitfest.postgresql.org/patch/3821/ for reference.
> >>
> >> Of course — I’ve added Diogo Repas, Zhicheng Luo, and Mahmoud Sakr as
> > authors as we
> >
> >> Regards,
> >> Maxime
> >>
> > Thanks for the reference.
> >
> > Best regards,
> > Haibo
>
>
> One thing that might be a problem is that rangejoinsel and
> multirangejoinsel (0002) look like they use the bounds histogram without
> the statistic_proc_security_check() that calc_hist_selectivity does just
> above. If I follow it correctly, that runs the cmp/subdiff over another
> role's histogram at plan time, before the permission check, which I
> believe is what CVE-2017-7484 guarded against.
>

Hi Bryan,
Thanks you for catching this.

I independently verified the issue, and the concern is valid for both patch 1
and patch 2. Both `rangejoinsel()` and `multirangejoinsel()` can pass
protected bounds-histogram values to the range support functions during
planning without first calling `statistic_proc_security_check()`.

Both support functions are reachable in this path:

the range comparator through `range_cmp_bounds()`
the subtype-difference function through
`calc_hist_selectivity_scalar()` / `get_position()`

Since the join estimator consumes statistics from both sides, the security
check also needs to be applied to both `vardata1` and `vardata2`.

Attached is v9 with the fix folded into the existing series:

patch 1 adds the security checks to `rangejoinsel()`
patch 2 adds the equivalent checks to `multirangejoinsel()`
patch 3 is unchanged in content

The checks are performed before histogram values are deserialized/used. If
either support function is unsafe for either side, the estimator follows the
existing cleanup path and falls back to the existing default selectivity.

I also added regression coverage to `privileges.sql`, alongside the existing
selfuncs/statistics security tests. The test independently covers both
failure modes — a non-LEAKPROOF comparator and a non-LEAKPROOF
subtype-difference function — for both range and multirange join estimation
under RLS. I verified that reverting only the two source-code security gates
makes those tests fail as expected.

The targeted regression tests and the full regression suite pass with v9.

Thanks again for spotting this.

Regards,
Haibo

>
> --
> Bryan Green
> EDB: https://www.enterprisedb.com