pgsql: Improve error message for MaxAllocSize overrun in accumArrayResu
Improve error message for MaxAllocSize overrun in accumArrayResult. Before, if you went past about 64M array elements in array_agg() and allied functions, you got a generic "invalid memory alloc request size" error. This patch replaces that with "array size exceeds the maximum allowed", which seems more user-friendly since it points you to needing to reduce the size of your array result. (This is the same error text you'd get from construct_md_array in the event of overrunning the maximum physical size for the finished array.) Per question from Shaozhong Shi. Since this hasn't come up often, I don't feel a need to back-patch. Discussion: https://postgr.es/m/ca+i5jwytvs9z2e71pcnkavpbon4r2wuj-lqbjsyr_xoz73q...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b8d3dae00f6c49d0c41abd5b36e2588a81abe5be Modified Files -- src/backend/utils/adt/arrayfuncs.c | 6 ++ 1 file changed, 6 insertions(+)
pgsql: Allow plan nodes with initPlans to be considered parallel-safe.
Allow plan nodes with initPlans to be considered parallel-safe. If the plan itself is parallel-safe, and the initPlans are too, there's no reason anymore to prevent the plan from being marked parallel-safe. That restriction (dating to commit ab77a5a45) was really a special case of the fact that we couldn't transmit subplans to parallel workers at all. We fixed that in commit 5e6d8d2bb and follow-ons, but this case never got addressed. We still forbid attaching initPlans to a Gather node that's inserted pursuant to debug_parallel_query = regress. That's because, when we hide the Gather from EXPLAIN output, we'd hide the initPlans too, causing cosmetic regression diffs. It seems inadvisable to kluge EXPLAIN to the extent required to make the output look the same, so just don't do it in that case. Along the way, this also takes care of some sloppiness about updating path costs to match when we move initplans from one place to another during createplan.c and setrefs.c. Since all the planning decisions are already made by that point, this is just cosmetic; but it seems good to keep EXPLAIN output consistent with where the initplans are. The diff in query_planner() might be worth remarking on. I found that one because after fixing things to allow parallel-safe initplans, one partition_prune test case changed plans (as shown in the patch) --- but only when debug_parallel_query was active. The reason proved to be that we only bothered to mark Result nodes as potentially parallel-safe when debug_parallel_query is on. This neglects the fact that parallel-safety may be of interest for a sub-query even though the Result itself doesn't parallelize. Discussion: https://postgr.es/m/1129530.1681317...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e08d74ca1342cb9e6047daad2019b550ecf54877 Modified Files -- src/backend/optimizer/plan/createplan.c | 15 +++-- src/backend/optimizer/plan/planmain.c | 15 +++-- src/backend/optimizer/plan/planner.c | 36 +--- src/backend/optimizer/plan/setrefs.c | 32 ++ src/backend/optimizer/plan/subselect.c| 84 +-- src/backend/optimizer/util/pathnode.c | 18 +- src/include/optimizer/subselect.h | 3 + src/test/regress/expected/partition_prune.out | 37 +--- 8 files changed, 169 insertions(+), 71 deletions(-)
pgsql: Account for optimized MinMax aggregates during SS_finalize_plan.
Account for optimized MinMax aggregates during SS_finalize_plan. We are capable of optimizing MIN() and MAX() aggregates on indexed columns into subqueries that exploit the index, rather than the normal thing of scanning the whole table. When we do this, we replace the Aggref node(s) with Params referencing subquery outputs. Such Params really ought to be included in the per-plan-node extParam/allParam sets computed by SS_finalize_plan. However, we've never done so up to now because of an ancient implementation choice to perform that substitution during set_plan_references, which runs after SS_finalize_plan, so that SS_finalize_plan never sees these Params. This seems like clearly a bug, yet there have been no field reports of problems that could trace to it. This may be because the types of Plan nodes that could contain Aggrefs do not have any of the rescan optimizations that are controlled by extParam/allParam. Nonetheless it seems certain to bite us someday, so let's fix it in a self-contained patch that can be back-patched if we find a case in which there's a live bug pre-v17. The cleanest fix would be to perform a separate tree walk to do these substitutions before SS_finalize_plan runs. That seems unattractive, first because a whole-tree mutation pass is expensive, and second because we lack infrastructure for visiting expression subtrees in a Plan tree, so that we'd need a new function knowing as much as SS_finalize_plan knows about that. I also considered swapping the order of SS_finalize_plan and set_plan_references, but that fell foul of various assumptions that seem tricky to fix. So the approach adopted here is to teach SS_finalize_plan itself to check for such Aggrefs. I refactored things a bit in setrefs.c to avoid having three copies of the code that does that. Given the lack of any currently-known bug, no test case here. Discussion: https://postgr.es/m/2391880.1689025...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d0d44049d1262aed2eee906d26af852948206db0 Modified Files -- src/backend/optimizer/plan/setrefs.c | 68 +- src/backend/optimizer/plan/subselect.c | 25 +++-- src/include/optimizer/planmain.h | 2 + 3 files changed, 66 insertions(+), 29 deletions(-)
pgsql: Simplify option handling in pg_ctl.
Simplify option handling in pg_ctl. Now that the in-tree getopt_long() moves non-options to the end of argv (see commit 411b720343), we can remove pg_ctl's workaround for getopt_long() implementations that don't reorder argv. Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/20230713034903.GA991765%40nathanxps13 Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/03d1080d8a95d7ced90043f3aaad7d2aaeaedb1b Modified Files -- src/bin/pg_ctl/pg_ctl.c | 268 +++- 1 file changed, 128 insertions(+), 140 deletions(-)
