Re: Reducing the chunk header sizes on all memory context types - Mailing list pgsql-hackers

From David Rowley
Subject Re: Reducing the chunk header sizes on all memory context types
Date
Msg-id CAApHDvomyTrKGXU4PVnUEeauaNgjRppJ2Myb+MwWMU47was6Qg@mail.gmail.com
Whole thread Raw
In response to Re: Reducing the chunk header sizes on all memory context types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reducing the chunk header sizes on all memory context types
List pgsql-hackers
On Tue, 30 Aug 2022 at 03:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I'd suggest reverting df0f4feef as it seems to be
> a red herring.

I think it's useless providing that a 64-bit variable will always be
aligned to 8 bytes on all of our supported 32-bit platforms as,
without the padding, the uint64 hdrmask in MemoryChunk will always be
aligned to 8 bytes meaning the memory following that will be aligned
too.  If we have a platform where a uint64 isn't aligned to 8 bytes
then we might need the padding.

long long seems to align to 8 bytes on my 32-bit Rasberry PI going the
struct being 16 bytes rather than 12.

drowley@raspberrypi:~ $ cat struct.c
#include <stdio.h>

typedef struct test
{
        int a;
        long long b;
} test;

int main(void)
{
        printf("%d\n", sizeof(test));
        return 0;
}
drowley@raspberrypi:~ $ gcc struct.c -o struct
drowley@raspberrypi:~ $ ./struct
16
drowley@raspberrypi:~ $ uname -m
armv7l

Is that the case for your 32-bit PPC too?

David



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: use ARM intrinsics in pg_lfind32() where available
Next
From: Andres Freund
Date:
Subject: Re: configure openldap crash warning