pgsql: Flush Memoize cache when non-key parameters change
Flush Memoize cache when non-key parameters change
It's possible that a subplan below a Memoize node contains a parameter
from above the Memoize node. If this parameter changes then cache entries
may become out-dated due to the new parameter value.
Previously Memoize was mistakenly not aware of this. We fix this here by
flushing the cache whenever a parameter that's not part of the cache
key changes.
Bug: #17213
Reported by: Elvis Pranskevichus
Author: David Rowley
Discussion: /messages/by-id/17213-988ed34b225a2862@postgresql.org
Backpatch-through: 14, where Memoize was added
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/f94edb06ab60545a0e9e90aedc39e3b81b2b9e3f
Modified Files
--------------
src/backend/executor/nodeMemoize.c | 38 ++++++++++++++++++++++++++++++++
src/backend/nodes/bitmapset.c | 2 ++
src/backend/optimizer/plan/createplan.c | 10 ++++++---
src/backend/optimizer/util/clauses.c | 31 ++++++++++++++++++++++++++
src/include/nodes/execnodes.h | 2 ++
src/include/nodes/plannodes.h | 1 +
src/include/optimizer/clauses.h | 2 ++
src/test/regress/expected/memoize.out | 39 +++++++++++++++++++++++++++++++++
src/test/regress/sql/memoize.sql | 20 +++++++++++++++++
9 files changed, 142 insertions(+), 3 deletions(-)
On Wed, 24 Nov 2021 at 14:57, David Rowley <drowley@postgresql.org> wrote:
Flush Memoize cache when non-key parameters change
I'm currently looking into why the buildfarm does not like this.
David
On Wed, Nov 24, 2021 at 03:18:53PM +1300, David Rowley wrote:
I'm currently looking into why the buildfarm does not like this.
From what I can see, there are two separate problems here:
- force_parallel_mode = regress.
- -DRELCACHE_FORCE_RELEASE and/or -DCATCACHE_FORCE_RELEASE.
Regards,
--
Michael
On Wed, 24 Nov 2021 at 17:31, Michael Paquier <michael@paquier.xyz> wrote:
From what I can see, there are two separate problems here:
- force_parallel_mode = regress.
- -DRELCACHE_FORCE_RELEASE and/or -DCATCACHE_FORCE_RELEASE.
Thanks. I missed adding keyparamids to the copy/read/write functions.
David
On Wed, 24 Nov 2021 at 20:27, David Rowley <dgrowleyml@gmail.com> wrote:
On Wed, 24 Nov 2021 at 17:31, Michael Paquier <michael@paquier.xyz> wrote:
From what I can see, there are two separate problems here:
- force_parallel_mode = regress.
- -DRELCACHE_FORCE_RELEASE and/or -DCATCACHE_FORCE_RELEASE.Thanks. I missed adding keyparamids to the copy/read/write functions.
Looks like the cause of the animals that had the plan change [1]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2021-11-24%2002%3A04%3A18[2]https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2021-11-24%2002%3A24%3A03 is
a timing issue where tenk2 is not auto-analyzed before the Memoize
test. Due to the lack of stats, Memoize is not considered in the
planner.
I see tenk1 is manually ANALYZEd, so I'll just change the tests to use
tenk1 instead of tenk2.
David
[1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=serinus&dt=2021-11-24%2002%3A04%3A18
[2]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2021-11-24%2002%3A24%3A03