On Sun, Nov 17, 2024 at 01:26:38AM -0500, Tom Lane wrote:
> arcarray = (struct arc **) MALLOC(totalinarcs * sizeof(struct arc *));
> if (arcarray == NULL)
> {
> NERR(REG_ESPACE);
> ...
>
> On a machine where malloc(0) returns NULL, this mistakenly
> thinks that's an error.
>
> I verified that
>
> - if (arcarray == NULL)
> + if (arcarray == NULL && totalinarcs != 0)
>
> makes the failure go away, but I wonder if any other places in
> backend/regex/ are at the same hazard. Maybe the smartest fix
> would be to put in a wrapper layer that does what pg_malloc
> does:
>
> /* Avoid unportable behavior of malloc(0) */
> if (size == 0)
> size = 1;
Either of those sound reasonable. The consequence of missing this hazard, a
deterministic ERROR, is modest. This affects just one platform, in the oldest
branches. There's a lack of complaints. To me, all that would make the
one-line diff tempting.
> One other point is that this theory fails to explain why
> hornet didn't fail in the v16 branch ... oh, wait:
> v15 has
>
> #define MALLOC(n) malloc(n)
>
> where later branches have
>
> #define MALLOC(n) palloc_extended((n), MCXT_ALLOC_NO_OOM)
>
> So the right answer seems to be to figure out why we didn't
> back-patch that change.
I don't recall a specific reason or see one in the discussion of commit
bea3d7e38. It was done mainly to unblock commit db4f21e, which in turn
unblocked commit 0da096d. The last commit is heavy, so I can understand it
skipping the back branches. If I were making a (weak) argument against
back-patching bea3d7e38, I might cite the extra memory use from
RegexpCacheMemoryContext and children.
