Re: Use pg_malloc macros in src/fe_utils

From: Andreas Karlsson <andreas(at)proxel(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Henrik TJ <henrik(at)0x48(dot)dk>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Use pg_malloc macros in src/fe_utils
Date: 2026-02-27 01:15:46
Message-ID: cfb645da-6b3a-4f22-9bcc-5bc46b0e9c61@proxel.se
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/24/26 4:36 AM, Michael Paquier wrote:
> On Mon, Feb 23, 2026 at 03:17:52AM +0100, Andreas Karlsson wrote:
>> Looks like a nice change but why not just fix all instances of it in one
>> swoop? It cannot be that many as there are 166 calls to pg_malloc() and 62
>> calls to pg_malloc0() after your patch that need to be looked at.
>
> FWIW, I don't really mind if these changes are proposed gradually, and
> this looked fine enough on its own. So applied.

Fair, here is a patch which should handle all uses in the frontend code
so we follow this pattern consistently to encourage new code to use
these macros.

When doing this I found two things which I am ot sure what the cleanest
way to handle would be so I broke them out into separate patches.

1. What should we do about when we allocate a an array of characters?
Would it make sense to use pg_array_alloc() or would that jsut be silly?
For example:

-pad = (char *) pg_malloc(l + 1);
+pad = pg_malloc_array(char, l + 1);

2. I found a small and harmless thinko. The buffer in verify_tar_file()
is actually a char * but for some reason the code did the following:

buffer = pg_malloc(READ_CHUNK_SIZE * sizeof(uint8));

What should we do about it? Just skip the "sizof(uint8)"?

Andreas

Attachment Content-Type Size
v1-0001-Use-pg_malloc_object-and-pg_alloc_array-variants-.patch text/x-patch 50.7 KB
v1-0002-TODO-What-to-do-about-when-we-allocate-an-array-o.patch text/x-patch 2.9 KB
v1-0003-TODO-uint8-vs-char-confusion.patch text/x-patch 856 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-02-27 01:33:45 Re: guc: make dereference style consistent in check_backtrace_functions
Previous Message Fujii Masao 2026-02-27 01:12:43 Re: Improve checks for GUC recovery_target_xid