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 по дате отправления: