Re: Making type Datum be 8 bytes everywhere

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas@vondra.me>
Cc: Peter Eisentraut <peter@eisentraut.org>, Joe Conway <mail@joeconway.com>, Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>
Date: 2025-09-10T21:35:04Z
Lists: pgsql-hackers
Tomas Vondra <tomas@vondra.me> writes:
> On 9/10/25 22:35, Tom Lane wrote:
>> 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.

I think it's just that i386 doesn't have hardware-level alignment
restrictions, or at least not ones for more than 4 bytes.

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

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

I can deal with it today, will go do so.

			regards, tom lane



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Avoid faulty alignment of Datums in build_sorted_items().

  2. Grab the low-hanging fruit from forcing USE_FLOAT8_BYVAL to true.

  3. Grab the low-hanging fruit from forcing sizeof(Datum) to 8.

  4. Make type Datum be 8 bytes wide everywhere.

  5. Mop-up for Datum conversion cleanups.