Re: Unexpected behavior after OOM errors

On Sat, Jul 18, 2026 at 09:47:43AM +0900, Michael Paquier wrote:
> On Fri, Jul 17, 2026 at 04:15:15PM +0200, Alex Masterov wrote:
>> This is the backend-local sibling of the shared/DSA-path issue fixed in
>> 8191e0c16a. Present since 5891c7a8ed8 (2022); affects PG15, PG17, PG18, and
>> master.
>
> Yeah, I can buy this one. MemoryContextAlloc() would fail an longjmp
> on OOM, so we'd better keep the backend data clean. Perhaps we should
> just use the Extended() flavor to bypass the failure and do cleanup
> actions.. Will look later.

On HEAD, I am getting a different symptom, which is still an incorrect
thing to have but I think that this is just because entry_ref finishes
with non-NULL garbage when the allocation fails due to the lose end of
the hash insert to caring about this data:
FATAL: releasing ref with pending data

But that's to me the same thing as what you are seeing. The only
difference is that I think that entry_ref is just pointing to some
garbage, making the assertion accidentally work.

So, what I think we should do is the attached:
- Switch to Extended(MCXT_ALLOC_NO_OOM)
- For the cases of !found and !cache_entry->entry_ref, clean up the
hash table if the allocation fails.

Actually, the found && !entry_ref has always been a kind of dead code
pattern? Due to the use an Alloc() that could fail, this would mess
up with the backend shutdown, which is worse than assuming that
entry_ref could be NULL on secondary lookup? Keeping the check is a
defensive thing, which is fine at the end. Just mentioning in
passing..

Alex, what do you think? That works with your scenario. The
injection point should be removed at the end, just kept it here to
demonstrate the problem reusing your scenario (leaks memory of course,
but we don't care as long as the hash table is left untouched).
--
Michael