Re: Unexpected behavior after OOM errors

On Fri, 17 Jul 2026 at 11:00, Alexander Lakhin <exclusion(at)gmail(dot)com> 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