agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Fix issue with RANGE's DEFAULT partition pruning 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix issue with RANGE's DEFAULT partition pruning @ 2026-07-31 03:36 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-07-31 03:36 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with RANGE's DEFAULT partition pruning Partition pruning for RANGE-partitioned tables could mistakenly prune the DEFAULT partition in some cases when it was not valid to do so, which could lead to rows missing from query results. The only known cases where this could happen is when combining pruning steps from an IS NOT NULL clause with other steps that matched to the DEFAULT partition. This could occur due to RANGE partitioned tables having two distinct internal representations for marking if the DEFAULT partition should be scanned. The IS NOT NULL steps would mark the "scan_default" boolean, but other steps created for different purposes could mark a bound_offset Bitmapset, which would ultimately translate into also scanning the default partition. This could all fail after multiple steps were combined with a combine intersect operator, as that will intersect the bound_offset bits and only set scan_default if all pruning steps have that flag set. When both input steps to the intersect operator had different representations of whether to scan the DEFAULT partition, the resulting intersect step result would contain neither representation. Here, we fix this by having the IS NOT NULL pruning result mark the bound_offsets so that it uses both representations to mark that the DEFAULT partition must be scanned. Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Diagnosed-by: Jacob Brazeal <jacob.brazeal@gmail.com> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CA+COZaDXrfTaBjLE=Z79MTaH6Xun1V4PeKxLvCNv8mXS8wn0rw@mail.gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/709dfd27f14f07ee87fd9707dc765d0338752b5a Modified Files -------------- src/backend/partitioning/partprune.c | 10 ++---- src/test/regress/expected/partition_prune.out | 46 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 20 ++++++++++++ 3 files changed, 68 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix issue with RANGE's DEFAULT partition pruning @ 2026-07-31 03:37 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-07-31 03:37 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with RANGE's DEFAULT partition pruning Partition pruning for RANGE-partitioned tables could mistakenly prune the DEFAULT partition in some cases when it was not valid to do so, which could lead to rows missing from query results. The only known cases where this could happen is when combining pruning steps from an IS NOT NULL clause with other steps that matched to the DEFAULT partition. This could occur due to RANGE partitioned tables having two distinct internal representations for marking if the DEFAULT partition should be scanned. The IS NOT NULL steps would mark the "scan_default" boolean, but other steps created for different purposes could mark a bound_offset Bitmapset, which would ultimately translate into also scanning the default partition. This could all fail after multiple steps were combined with a combine intersect operator, as that will intersect the bound_offset bits and only set scan_default if all pruning steps have that flag set. When both input steps to the intersect operator had different representations of whether to scan the DEFAULT partition, the resulting intersect step result would contain neither representation. Here, we fix this by having the IS NOT NULL pruning result mark the bound_offsets so that it uses both representations to mark that the DEFAULT partition must be scanned. Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Diagnosed-by: Jacob Brazeal <jacob.brazeal@gmail.com> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CA+COZaDXrfTaBjLE=Z79MTaH6Xun1V4PeKxLvCNv8mXS8wn0rw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/f9282a65058b30f0e10fc5dff0171bbd6eb9a254 Modified Files -------------- src/backend/partitioning/partprune.c | 10 ++---- src/test/regress/expected/partition_prune.out | 46 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 20 ++++++++++++ 3 files changed, 68 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix issue with RANGE's DEFAULT partition pruning @ 2026-07-31 03:38 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-07-31 03:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with RANGE's DEFAULT partition pruning Partition pruning for RANGE-partitioned tables could mistakenly prune the DEFAULT partition in some cases when it was not valid to do so, which could lead to rows missing from query results. The only known cases where this could happen is when combining pruning steps from an IS NOT NULL clause with other steps that matched to the DEFAULT partition. This could occur due to RANGE partitioned tables having two distinct internal representations for marking if the DEFAULT partition should be scanned. The IS NOT NULL steps would mark the "scan_default" boolean, but other steps created for different purposes could mark a bound_offset Bitmapset, which would ultimately translate into also scanning the default partition. This could all fail after multiple steps were combined with a combine intersect operator, as that will intersect the bound_offset bits and only set scan_default if all pruning steps have that flag set. When both input steps to the intersect operator had different representations of whether to scan the DEFAULT partition, the resulting intersect step result would contain neither representation. Here, we fix this by having the IS NOT NULL pruning result mark the bound_offsets so that it uses both representations to mark that the DEFAULT partition must be scanned. Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Diagnosed-by: Jacob Brazeal <jacob.brazeal@gmail.com> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CA+COZaDXrfTaBjLE=Z79MTaH6Xun1V4PeKxLvCNv8mXS8wn0rw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/02e69be47c05c10c8ee8ac5d7634a4048c037ebc Modified Files -------------- src/backend/partitioning/partprune.c | 10 ++---- src/test/regress/expected/partition_prune.out | 46 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 20 ++++++++++++ 3 files changed, 68 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix issue with RANGE's DEFAULT partition pruning @ 2026-07-31 03:38 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-07-31 03:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with RANGE's DEFAULT partition pruning Partition pruning for RANGE-partitioned tables could mistakenly prune the DEFAULT partition in some cases when it was not valid to do so, which could lead to rows missing from query results. The only known cases where this could happen is when combining pruning steps from an IS NOT NULL clause with other steps that matched to the DEFAULT partition. This could occur due to RANGE partitioned tables having two distinct internal representations for marking if the DEFAULT partition should be scanned. The IS NOT NULL steps would mark the "scan_default" boolean, but other steps created for different purposes could mark a bound_offset Bitmapset, which would ultimately translate into also scanning the default partition. This could all fail after multiple steps were combined with a combine intersect operator, as that will intersect the bound_offset bits and only set scan_default if all pruning steps have that flag set. When both input steps to the intersect operator had different representations of whether to scan the DEFAULT partition, the resulting intersect step result would contain neither representation. Here, we fix this by having the IS NOT NULL pruning result mark the bound_offsets so that it uses both representations to mark that the DEFAULT partition must be scanned. Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Diagnosed-by: Jacob Brazeal <jacob.brazeal@gmail.com> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CA+COZaDXrfTaBjLE=Z79MTaH6Xun1V4PeKxLvCNv8mXS8wn0rw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/31f2acde53d2b8c289614dcf47d40cad8daf7750 Modified Files -------------- src/backend/partitioning/partprune.c | 10 ++---- src/test/regress/expected/partition_prune.out | 46 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 20 ++++++++++++ 3 files changed, 68 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix issue with RANGE's DEFAULT partition pruning @ 2026-07-31 03:38 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-07-31 03:38 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with RANGE's DEFAULT partition pruning Partition pruning for RANGE-partitioned tables could mistakenly prune the DEFAULT partition in some cases when it was not valid to do so, which could lead to rows missing from query results. The only known cases where this could happen is when combining pruning steps from an IS NOT NULL clause with other steps that matched to the DEFAULT partition. This could occur due to RANGE partitioned tables having two distinct internal representations for marking if the DEFAULT partition should be scanned. The IS NOT NULL steps would mark the "scan_default" boolean, but other steps created for different purposes could mark a bound_offset Bitmapset, which would ultimately translate into also scanning the default partition. This could all fail after multiple steps were combined with a combine intersect operator, as that will intersect the bound_offset bits and only set scan_default if all pruning steps have that flag set. When both input steps to the intersect operator had different representations of whether to scan the DEFAULT partition, the resulting intersect step result would contain neither representation. Here, we fix this by having the IS NOT NULL pruning result mark the bound_offsets so that it uses both representations to mark that the DEFAULT partition must be scanned. Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Diagnosed-by: Jacob Brazeal <jacob.brazeal@gmail.com> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CA+COZaDXrfTaBjLE=Z79MTaH6Xun1V4PeKxLvCNv8mXS8wn0rw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9a0cd8e73f52307162f0c81e2d6e52c79f5592c3 Modified Files -------------- src/backend/partitioning/partprune.c | 10 ++---- src/test/regress/expected/partition_prune.out | 46 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 20 ++++++++++++ 3 files changed, 68 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix issue with RANGE's DEFAULT partition pruning @ 2026-07-31 03:39 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-07-31 03:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with RANGE's DEFAULT partition pruning Partition pruning for RANGE-partitioned tables could mistakenly prune the DEFAULT partition in some cases when it was not valid to do so, which could lead to rows missing from query results. The only known cases where this could happen is when combining pruning steps from an IS NOT NULL clause with other steps that matched to the DEFAULT partition. This could occur due to RANGE partitioned tables having two distinct internal representations for marking if the DEFAULT partition should be scanned. The IS NOT NULL steps would mark the "scan_default" boolean, but other steps created for different purposes could mark a bound_offset Bitmapset, which would ultimately translate into also scanning the default partition. This could all fail after multiple steps were combined with a combine intersect operator, as that will intersect the bound_offset bits and only set scan_default if all pruning steps have that flag set. When both input steps to the intersect operator had different representations of whether to scan the DEFAULT partition, the resulting intersect step result would contain neither representation. Here, we fix this by having the IS NOT NULL pruning result mark the bound_offsets so that it uses both representations to mark that the DEFAULT partition must be scanned. Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Diagnosed-by: Jacob Brazeal <jacob.brazeal@gmail.com> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CA+COZaDXrfTaBjLE=Z79MTaH6Xun1V4PeKxLvCNv8mXS8wn0rw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5190732c91f0327a3a78697d715f1ea1f0e14a2f Modified Files -------------- src/backend/partitioning/partprune.c | 10 ++---- src/test/regress/expected/partition_prune.out | 46 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 20 ++++++++++++ 3 files changed, 68 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix issue with RANGE's DEFAULT partition pruning @ 2026-07-31 03:39 David Rowley <drowley@postgresql.org> 0 siblings, 0 replies; 7+ messages in thread From: David Rowley @ 2026-07-31 03:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix issue with RANGE's DEFAULT partition pruning Partition pruning for RANGE-partitioned tables could mistakenly prune the DEFAULT partition in some cases when it was not valid to do so, which could lead to rows missing from query results. The only known cases where this could happen is when combining pruning steps from an IS NOT NULL clause with other steps that matched to the DEFAULT partition. This could occur due to RANGE partitioned tables having two distinct internal representations for marking if the DEFAULT partition should be scanned. The IS NOT NULL steps would mark the "scan_default" boolean, but other steps created for different purposes could mark a bound_offset Bitmapset, which would ultimately translate into also scanning the default partition. This could all fail after multiple steps were combined with a combine intersect operator, as that will intersect the bound_offset bits and only set scan_default if all pruning steps have that flag set. When both input steps to the intersect operator had different representations of whether to scan the DEFAULT partition, the resulting intersect step result would contain neither representation. Here, we fix this by having the IS NOT NULL pruning result mark the bound_offsets so that it uses both representations to mark that the DEFAULT partition must be scanned. Reported-by: Jacob Brazeal <jacob.brazeal@gmail.com> Diagnosed-by: Jacob Brazeal <jacob.brazeal@gmail.com> Author: David Rowley <dgrowleyml@gmail.com> Discussion: https://postgr.es/m/CA+COZaDXrfTaBjLE=Z79MTaH6Xun1V4PeKxLvCNv8mXS8wn0rw@mail.gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6098f35f44ef7df3ec829c4c1e69d015a0136ad3 Modified Files -------------- src/backend/partitioning/partprune.c | 10 ++---- src/test/regress/expected/partition_prune.out | 46 +++++++++++++++++++++++++++ src/test/regress/sql/partition_prune.sql | 20 ++++++++++++ 3 files changed, 68 insertions(+), 8 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-07-31 03:39 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-07-31 03:36 pgsql: Fix issue with RANGE's DEFAULT partition pruning David Rowley <drowley@postgresql.org> 2026-07-31 03:37 pgsql: Fix issue with RANGE's DEFAULT partition pruning David Rowley <drowley@postgresql.org> 2026-07-31 03:38 pgsql: Fix issue with RANGE's DEFAULT partition pruning David Rowley <drowley@postgresql.org> 2026-07-31 03:38 pgsql: Fix issue with RANGE's DEFAULT partition pruning David Rowley <drowley@postgresql.org> 2026-07-31 03:38 pgsql: Fix issue with RANGE's DEFAULT partition pruning David Rowley <drowley@postgresql.org> 2026-07-31 03:39 pgsql: Fix issue with RANGE's DEFAULT partition pruning David Rowley <drowley@postgresql.org> 2026-07-31 03:39 pgsql: Fix issue with RANGE's DEFAULT partition pruning David Rowley <drowley@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox