Re: Expand palloc/pg_malloc API

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Expand palloc/pg_malloc API
Date: 2022-08-12 07:39:43
Message-ID: 8a844750-ba6a-4a32-3bc9-2ba73224b4df@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 27.07.22 01:58, David G. Johnston wrote:
> Admittedly I'm still getting my head around reading pointer-using code
> (I get the general concept but haven't had to code them)....
>
> - lockrelid = palloc(sizeof(*lockrelid));
> + lockrelid = palloc_ptrtype(lockrelid);
>
> // This definitely seems like an odd idiom until I remembered about
> short-lived memory contexts and the lost pointers are soon destroyed there.
>
> So lockrelid (no star) is a pointer that has an underlying reference
> that the macro (and the orignal code) resolves via the *
>
> I cannot reason out whether the following would be equivalent to the above:
>
> lockrelid = palloc_obj(*lockrelid);

I think that would also work.

Ultimately, it would be more idiomatic (in Postgres), to write this as

lockrelid = palloc(sizeof(LockRelId));

and thus

lockrelid = palloc_obj(LockRelId);

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-08-12 07:42:30 Re: Cleaning up historical portability baggage
Previous Message Peter Eisentraut 2022-08-12 07:31:40 Re: Expand palloc/pg_malloc API