Re: Making type Datum be 8 bytes everywhere - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: Making type Datum be 8 bytes everywhere
Date
Msg-id CAEudQApPvk2UxqhmhNbTBkCA6JnUSBvJ3+47aMZy+VkFL1E_CQ@mail.gmail.com
Whole thread Raw
In response to Re: Making type Datum be 8 bytes everywhere  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


Em qui., 11 de set. de 2025 às 12:36, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
Ranier Vilela <ranier.vf@gmail.com> writes:
> Em qua., 10 de set. de 2025 às 17:35, Tom Lane <tgl@sss.pgh.pa.us> escreveu:
>> 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).

> We possibly have two more instances?

> 1. Function ndistinct_for_combination (src/backend/statistics/mvdistinct.c)
> - items = (SortItem *) palloc(numrows * sizeof(SortItem));
> + items = (SortItem *) palloc(MAXALIGN(numrows * sizeof(SortItem)));

> 2. Function build_distinct_groups (src/backend/statistics/mcv.c)
> - SortItem   *groups = (SortItem *) palloc(ngroups * sizeof(SortItem));
> + SortItem   *groups = (SortItem *) palloc(MAXALIGN(ngroups *
> sizeof(SortItem)));

Neither of those have any hazard, because they are not trying to
allocate multiple arrays using address arithmetic.  The part of
build_sorted_items that was actually problematic was doing

        ptr += data->numrows * sizeof(SortItem);

and then assuming that the result was suitably aligned to be
cast to Datum*.
Thanks Tom, for double checking.

best regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: OAuth client code doesn't work with Google OAuth
Next
From: Tom Lane
Date:
Subject: Re: ALTER DATABASE RESET with unexistent guc doesn't report an error