aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeProjectSet.c
diff options
context:
space:
mode:
authorDavid Rowley <drowley@postgresql.org>2024-03-11 18:20:39 +1300
committerDavid Rowley <drowley@postgresql.org>2024-03-11 18:20:39 +1300
commit348233cb128d32fd3a61f4473eda9564efdcd29c (patch)
tree196390fd4b234e614474d5df45fa5a24fee88d7e /src/backend/executor/nodeProjectSet.c
parent7607671826dd3050b2656700cf1a9cc99a73a4df (diff)
downloadpostgresql-348233cb128d32fd3a61f4473eda9564efdcd29c.tar.gz
postgresql-348233cb128d32fd3a61f4473eda9564efdcd29c.zip
Fix incorrect accessing of pfree'd memory in Memoize
For pass-by-reference types, the code added in 0b053e78b, which aimed to resolve a memory leak, was overly aggressive in resetting the per-tuple memory context which could result in pfree'd memory being accessed resulting in failing to find previously cached results in the hash table. What was happening was prepare_probe_slot() was switching to the per-tuple memory context and calling ExecEvalExpr(). ExecEvalExpr() may have required a memory allocation. Both MemoizeHash_hash() and MemoizeHash_equal() were aggressively resetting the per-tuple context and after determining the hash value, the context would have gotten reset before MemoizeHash_equal() was called. This could have resulted in MemoizeHash_equal() looking at pfree'd memory. This is less likely to have caused issues on a production build as some other allocation would have had to have reused the pfree'd memory to overwrite it. Otherwise, the original contents would have been intact. However, this clearly caused issues on MEMORY_CONTEXT_CHECKING builds. Author: Tender Wang, Andrei Lepikhov Reported-by: Tender Wang (using SQLancer) Reviewed-by: Andrei Lepikhov, Richard Guo, David Rowley Discussion: https://postgr.es/m/CAHewXNnT6N6UJkya0z-jLFzVxcwGfeRQSfhiwA+NyLg-x8iGew@mail.gmail.com Backpatch-through: 14, where Memoize was added
Diffstat (limited to 'src/backend/executor/nodeProjectSet.c')
0 files changed, 0 insertions, 0 deletions