Re: Partition pruning can incorrectly exclude a RANGE default partition

From: Tender Wang <tndrwang(at)gmail(dot)com>
To: Jacob Brazeal <jacob(dot)brazeal(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Partition pruning can incorrectly exclude a RANGE default partition
Date: 2026-07-27 11:34:24
Message-ID: CAHewXNnvJHkSgejRupWvFYOnO+081PyWaJsbcWfKGQzG9R2Yrg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tender Wang <tndrwang(at)gmail(dot)com> 于2026年7月27日周一 18:41写道:
>
> Tender Wang <tndrwang(at)gmail(dot)com> 于2026年7月27日周一 17:48写道:
> >
> > Yes, it seems that we should use step_result instead of result in
> > perform_pruning_combine_step().
> > After replacing it, I get the correct result.
> > diff --git a/src/backend/partitioning/partprune.c
> > b/src/backend/partitioning/partprune.c
> > index e7c318bbcac..8eedb6cce16 100644
> > --- a/src/backend/partitioning/partprune.c
> > +++ b/src/backend/partitioning/partprune.c
> > @@ -3685,9 +3685,9 @@
> > perform_pruning_combine_step(PartitionPruneContext *context,
> >
> > step_result->bound_offsets);
> >
> > /* Update whether to scan null
> > and default partitions. */
> > - if (result->scan_null)
> > + if (step_result->scan_null)
> > result->scan_null =
> > step_result->scan_null;
> > - if (result->scan_default)
> > + if (step_result->scan_default)
> > result->scan_default =
> > step_result->scan_default;
> >
> > postgres=# SELECT count(*) FROM s2
> > WHERE a IS NOT NULL
> > AND a IN (5, 15);
> > count
> > -------
> > 2
> > (1 row)
> >
> > postgres=# SET plan_cache_mode = force_generic_plan;
> > SET
> > postgres=# PREPARE s2p(int, int) AS
> > SELECT count(*) FROM s2
> > WHERE a IS NOT NULL
> > AND a IN ($1, $2);
> > PREPARE
> > postgres=# execute s2p(5,15);
> > count
> > -------
> > 2
> > (1 row)
> >
> > See the attached patch. (no test ).
> >
> The attached patch I wrote in the last email may be wrong. Because
> some cases in the regression failed.
> After digging deep into this issue, the problem seems to be with
> processing (5,15); to be more precise, it is processing 15.
> See the debug info:
> PartitionPruneStepOp [step_id=0]
> [opstrategy=3]
> [exprs]
> Const [consttype=23 constlen=4 constvalue=5
> constisnull=false constbyval=true]
> [cmpfns] OidList: [351]
> (gdb) n
> (gdb) pgprint argsteps
> PartitionPruneStepOp [step_id=1]
> [opstrategy=3]
> [exprs]
> Const [consttype=23 constlen=4 constvalue=15
> constisnull=false constbyval=true]
> [cmpfns] OidList: [351]
>
> The above steps are processing (5,15). When we process 15 in (5,15),
> the result is :
>
> PruneStepResult [scan_default=false scan_null=false]
> [bound_offsets] Bitmapset [2]
>
> We should scan the default partition, and perform_pruning_base_step()
> returned the above result.
> But the scan_default flag is false; I think it should be true here.

I tried the following:

diff --git a/src/backend/partitioning/partprune.c
b/src/backend/partitioning/partprune.c
index e7c318bbcac..96649580e6f 100644
--- a/src/backend/partitioning/partprune.c
+++ b/src/backend/partitioning/partprune.c
@@ -3170,6 +3170,8 @@ get_matching_range_bounds(PartitionPruneContext *context,
* end up adding the first bound's
offset, that is, 0.
*/
result->bound_offsets =
bms_make_singleton(off + 1);
+ if (off == boundinfo->default_index)
+ result->scan_default = true;
}

return result;

This time all cases in regression passed.
Any thoughts?

--
Thanks,
Tender Wang

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2026-07-27 11:35:10 Re: Bug: XLogReader mishandles oversized multi-page xl_tot_len (potential memory corruption)
Previous Message ayoub.kazar 2026-07-27 11:10:55 Re: [PATCH] Rewrite undirected edge patterns in GRAPH_TABLE using UNION ALL