Re: Making type Datum be 8 bytes everywhere
| От | Tom Lane |
|---|---|
| Тема | Re: Making type Datum be 8 bytes everywhere |
| Дата | |
| Msg-id | 1787515.1757604980@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Making type Datum be 8 bytes everywhere (Ranier Vilela <ranier.vf@gmail.com>) |
| Ответы |
Re: Making type Datum be 8 bytes everywhere
|
| Список | pgsql-hackers |
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*.
regards, tom lane
В списке pgsql-hackers по дате отправления: