From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andreas Karlsson <andreas(at)proxel(dot)se> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Add assertion for failed alloc to palloc0() and palloc_extended() |
Date: | 2025-03-03 04:13:05 |
Message-ID: | Z8UsUQ5fHpHujXXT@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 01, 2025 at 01:05:43AM +0100, Andreas Karlsson wrote:
> I noticed that we have Assert(ret != NULL) in palloc() but not in palloc0()
> so for consistency I decided to add it. I also added an assertion that the
> MCXT_ALLOC_NO_OOM flag is set if alloc() returns
> NULL to palloc_extended().
>
> I feel that this might be useful since while palloc() is much more common
> the OOM which causes alloc() to incorrectly return NULL could in theory
> happen in any of the three functions.
Hmm. Good points. All the MemoryContextMethods rely on
MemoryContextAllocationFailure() to handle the case of
MCXT_ALLOC_NO_OOM on failure (except alignedalloc which has no alloc
routine). Your two suggestions, one in palloc0() for the non-NULL
check, and the second one in palloc_extended() to make sure that we
have MCXT_ALLOC_NO_OOM set when the result is NULL, could catch
inconsistencies when implementing a new method.
In short, LGTM. Will apply if there are no objections.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Jacob Brazeal | 2025-03-03 05:05:47 | Accidental assignment instead of compare in GetOperatorFromCompareType? |
Previous Message | Fujii Masao | 2025-03-03 04:10:48 | Re: Change log level for notifying hot standby is waiting non-overflowed snapshot |