Reintroduce hash_mem cap on buckets in BuildTupleHashTable 8f29467c5 removed the hash_mem cap from the nbuckets calculation in BuildTupleHashTable() and put the trust into the planner to provide that function with a sane value, which it would only cap at 2^32. There are various places in the planner which cannot provide good estimates here and it's been demonstrated that it's not difficult to craft a query which requests 2^32 buckets.
Here we reintroduce the sanity checks so we don't end up making the hash table's initial size to something that would exceed hash_mem. This may cause the hash table to have to grow several times before it fills, but that seems much better than having the executor OOM due to the request being too large. Users are also used to work_mem and hash_mem_multiplier having an effect on query performance, so this shouldn't be too surprising. It also restores the limits that were imposed pre-8f29467c5, which were tried and tested. Bug: #19759 Reported-by: Alperen Keles <[email protected]> Author: David Rowley <[email protected]> Reviewed-by: shihao zhong <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 19 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/34d52e6d3daa7dfeecddc32be91f7d5ee4dcb92f Modified Files -------------- src/backend/executor/execGrouping.c | 35 +++++++++++++++++++++++++++-------- 1 file changed, 27 insertions(+), 8 deletions(-)
