Re: Making type Datum be 8 bytes everywhere

On 9/10/25 22:35, Tom Lane wrote:
> Tomas Vondra <tomas@vondra.me> writes:
>> While testing a different patch, I tried running with address sanitizer
>> on rpi5, running the 32-bit OS (which AFAIK is 64-bit kernel and 32-bit
>> user space). With that, stats_ext regression tests fail like this:
> 
>> extended_stats.c:1082:27: runtime error: store to misaligned address
>> 0x036671dc for type 'Datum', which requires 8 byte alignment
>> 0x036671dc: note: pointer points here
>>   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 7e
>> 7f  08 00 00 00 7f 7f 7f 7f
>>               ^

> 
>> This happens because build_sorted_items() does palloc(), and then
>> accesses the pointer as array of structs, with a Datum field. And it
>> apparently expects the pointer to be a multiple of 8 bytes. Isn't that a
>> bit strange, with 32-bit user space? The pointer is indeed a multiple of
>> 4B, so maybe the expected alignment is wrong?
> 
> I think build_sorted_items is plainly at fault here, where it does
> 
>     /* Compute the total amount of memory we need (both items and values). */
>     len = data->numrows * sizeof(SortItem) + nvalues * (sizeof(Datum) + sizeof(bool));
> 
>     /* Allocate the memory and split it into the pieces. */
>     ptr = palloc0(len);
> 
>     /* items to sort */
>     items = (SortItem *) ptr;
>     ptr += data->numrows * sizeof(SortItem);
> 
>     /* values and null flags */
>     values = (Datum *) ptr;
>     ptr += nvalues * sizeof(Datum);
> 
> This is silently assuming that sizeof(SortItem) is a multiple of
> alignof(Datum), which on a 32-bit-pointer platform is not true
> any longer.  We ought to MAXALIGN the two occurrences of
> data->numrows * sizeof(SortItem).
> 

You're right, I misunderstood which of the accesses is triggering the
report. I added the two MAXALIGNs and can confirm that makes it go away
on the rpi5. It's interesting it didn't happen on the i386 machine at
all, but I don't have time to look at why right now.

> Do you want to fix it, or shall I?
> 

Feel free to do so. If not, I'll do that on Monday.


Thanks

-- 
Tomas Vondra