diff options
| author | David Rowley <drowley@postgresql.org> | 2024-11-06 09:16:00 +1300 |
|---|---|---|
| committer | David Rowley <drowley@postgresql.org> | 2024-11-06 09:16:00 +1300 |
| commit | 87f81a55632107006e5006a2d0bc5272ebaeca64 (patch) | |
| tree | 043d6d39f4ba0121ba4363a4277a891480b52d84 /src/backend/jit/llvm/SectionMemoryManager.cpp | |
| parent | 7bdaa4b54208afe0d0fc691877da920016db6987 (diff) | |
| download | postgresql-87f81a55632107006e5006a2d0bc5272ebaeca64.tar.gz postgresql-87f81a55632107006e5006a2d0bc5272ebaeca64.zip | |
Fix hypothetical bug in ExprState building for hashing
adf97c156 gave ExprStates the ability to hash expressions and return a
single hash value. That commit supports seeding the hash value with an
initial value to have that blended into the final hash value.
Here we fix a hypothetical bug where if there are zero expressions to
hash, the initial value is stored in the wrong location. The existing
code stored the initial value in an intermediate location expecting that
when the expressions were hashed that those steps would store the final
hash value in the ExprState.resvalue field. However, that wouldn't happen
when there are zero expressions to hash. The correct thing to do instead
is to have a special case for zero expressions and when we hit that case,
store the initial value directly in the ExprState.resvalue. The reason
that this is a hypothetical bug is that no code currently calls
ExecBuildHash32Expr passing a non-zero initial value.
Discussion: https://postgr.es/m/CAApHDvpMAL_zxbMRr1LOex3O7Y7R7ZN2i8iUFLQhqQiJMAg3qw@mail.gmail.com
Diffstat (limited to 'src/backend/jit/llvm/SectionMemoryManager.cpp')
0 files changed, 0 insertions, 0 deletions