On Fri, 17 Jul 2026 at 11:00, Alexander Lakhin <[email protected]> wrote: > > Hello Michael and Matthias, > > Could you please look at other similar anomalies I have discovered?: > > (Assuming the attached OOM injection patch applied.) > 1) An issue in generate_partition_qual(): > --- a/src/backend/utils/cache/partcache.c > +++ b/src/backend/utils/cache/partcache.c > @@ -419,3 +419,5 @@ generate_partition_qual(Relation rel) > oldcxt = MemoryContextSwitchTo(rel->rd_partcheckcxt); > +oom_prob = 0.1; > rel->rd_partcheck = copyObject(result); > +oom_prob = 0; > MemoryContextSwitchTo(oldcxt); [...] > triggers > TRAP: failed Assert("cache->cc_tupdesc != NULL"), File: "catcache.c", Line: > 1112, PID: 43932
While the Assert is caused by other effects, it would still leave an incorrect rd_partcheck around in relcaches, so here's a patch that fixes that issue with rd_partcheckcxt. It also avoids leaking the context itself into the CacheMemoryContext when an OOM happens, so that's a neat addition. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
v1-0001-Fix-corrupted-caches-when-we-OOM-getting-the-part.patch
Description: Binary data
