Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
Date
Msg-id 787be980-0878-4f4a-be01-d042ab5d370e@iki.fi
Whole thread Raw
In response to Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
Re: PGPROC alignment (was Re: pgsql: Separate RecoveryConflictReasons from procsignals)
List pgsql-hackers
On 11/02/2026 06:40, Bertrand Drouvot wrote:
> A few comments:
> 
> 0001:
> 
> + * and (b) to make the multiplication / division to convert between PGPROC *
> + * and ProcNumber be a little cheaper
> 
> Is that correct if PGPROC size is not a power of 2?

You're right, it's not.

> 0002: Good catch!

Committed that.

>> With this, sizeof(PGPROC) == 864 without the explicit alignment to
>> PG_CACHE_LINE_SIZE, and 896 with it.
> 
> I can see 876 -> 896 on my side:
> 
> /*    872      |       4 */    uint32 wait_event_info;
> /* XXX 20-byte padding   */
> 
>                                 /* total size (bytes):  896 */
>                               }

Interesting. I've attached 'pahole bin/postgres' output from my laptop. 
It's Linux on arm64. This is with my v2 patches to rearrange the fields, 
but with the "pg_attribute_aligned(PG_CACHE_LINE_SIZE)" removed.

- Heikki

Attachment

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Questionable description about character sets
Next
From: Amit Kapila
Date:
Subject: Re: [Patch] add new parameter to pg_replication_origin_session_setup