summaryrefslogtreecommitdiff
path: root/src/backend/storage/ipc/procsignal.c
diff options
context:
space:
mode:
authorRichard Guo <rguo@postgresql.org>2025-11-05 18:09:21 +0900
committerRichard Guo <rguo@postgresql.org>2025-11-05 18:09:21 +0900
commitc1777f2d6d43adf9bc65da3e44a3a5ad2cbfa86d (patch)
treeeecf22f0efc3e3a2a4da3335a9ba55e6119d5668 /src/backend/storage/ipc/procsignal.c
parenta4fd971c6f534aff96a1b3aab61d8a498b6b4ac5 (diff)
Fix assertion failure in generate_orderedappend_paths()
In generate_orderedappend_paths(), there is an assumption that a child relation's row estimate is always greater than zero. There is an Assert verifying this assumption, and the estimate is also used to convert an absolute tuple count into a fraction. However, this assumption is not always valid -- for example, upper relations can have their row estimates unset, resulting in a value of zero. This can cause an assertion failure in debug builds or lead to the tuple fraction being computed as infinity in production builds. To fix, use the row estimate from the cheapest_total path to compute the tuple fraction. The row estimate in this path should already have been forced to a valid value. In passing, update the comment for generate_orderedappend_paths() to note that the function also considers the cheapest-fractional case when not all tuples need to be retrieved. That is, it collects all the cheapest fractional paths and builds an ordered append path for each interesting ordering. Backpatch to v18, where this issue was introduced. Bug: #19102 Reported-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com> Author: Richard Guo <guofenglinux@gmail.com> Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com> Reviewed-by: Andrei Lepikhov <lepihov@gmail.com> Discussion: https://postgr.es/m/19102-93480667e1200169@postgresql.org Backpatch-through: 18
Diffstat (limited to 'src/backend/storage/ipc/procsignal.c')
0 files changed, 0 insertions, 0 deletions