On Fri, 17 Jul 2026 at 11:00, Alexander Lakhin <[email protected]> wrote: > (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
> 2) lookup_type_cache():
> --- a/src/backend/utils/cache/typcache.c
> +++ b/src/backend/utils/cache/typcache.c
> @@ -463,8 +463,10 @@ lookup_type_cache(Oid type_id, int flags)
> in_progress_list[in_progress_offset] = type_id;
>
> +oom_prob = 0.1;
> /* Try to look up an existing entry */
> typentry = (TypeCacheEntry *) hash_search(TypeCacheHash,
> &type_id,
> HASH_FIND, NULL);
> +oom_prob = 0;
> if (typentry == NULL)
> {
[...]
> triggers
> TRAP: failed Assert("cache->cc_tupdesc != NULL"), File: "catcache.c", Line:
> 1112, PID: 43932
I think I found the source of these Asserts; the attached fixes it.
The problem is that we're registering the type entry handling as 'in
progress' before the cache is initialized, and the error handling hook
for in-progress type entries initializes the TYPEOID cache if there's
an in-progress entry and the cache wasn't already initialized. And,
initializing this catcache in non-transactional contexts isn't
allowed, so the error handling causes the assertion to fail.
It'd be nice if we could initialize a cache unconditionally without
relying on function's side effects, but the attached is a
(theoretically) backportable fix without changing code in unrelated
code.
Next, I'll be looking at the last issue.
Kind regards,
Matthias van de Meent
v1-0001-Fix-Assert-in-typcache.c.patch
Description: Binary data
