pgsql: Fix possible bogus cache miss bug in Memoize nodes

Fix possible bogus cache miss bug in Memoize nodes

When Memoize got a cache miss, it would create a new hash table entry
and execute its subnode to fetch the tuple to store in the cache. When
storing that tuple, the cache may have needed to make space for the new
tuple, and that could have resulted in older, less recently used entries
to be removed from the cache. The simplehash code, since it uses linear
probing to handle hash collisions, would shift subsequent elements back
towards their most optimal hash bucket when deleting items from the table.
This could result in the just-added entry being moved. The Memoize code
would then accidentally proceed to assign the entry's "complete" flag, but
the entry being modified there could have become stale as a result of the
simplehash code moving things around.

This could happen regardless of singlerow mode. In singlerow mode, it
could result in the entry being populated not correctly being marked as
complete, which could result in cache misses later that could have been
cache hits. When not in singlerow mode, an unrelated entry could have
been unmarked as complete accidentally, which could also have resulted
in cache misses that could have been hits. No wrong results were
possible from this.

Fix by using the entry pointer that's set in MemoizeState, which
cache_store_tuple() had so carefully rediscovered for that purpose.

Reported-by: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>
Author: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>
Reviewed-by: cca5507 <cca5507(at)qq(dot)com>
Reviewed-by: David Rowley <dgrowleyml(at)gmail(dot)com>
Discussion: https://postgr.es/m/14118dd4-eefa-42e4-ada7-900d6845d704@tantorlabs.com
Backpatch-through: 15

Branch
------
REL_15_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/75479d8d8ae9abf11989f7aa41ba82fcef77d22b

Modified Files
--------------
src/backend/executor/nodeMemoize.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)