From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Antonin Houska <ah(at)cybertec(dot)at> |
Subject: | Re: xl_heap_header alignment? |
Date: | 2020-07-21 18:33:23 |
Message-ID: | 1058724.1595356403@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On July 21, 2020 10:45:37 AM PDT, Antonin Houska <ah(at)cybertec(dot)at> wrote:
>> I don't quite understand this part of the comment of the xl_heap_header
>> structure:
>> * NOTE: t_hoff could be recomputed, but we may as well store it because
>> * it will come for free due to alignment considerations.
> Unless you declare them as packed, structs will add padding to align members correctly (if, and only if, the whole struct is stored well aligned).
I think that comment may be out of date, because what's there now is
* NOTE: t_hoff could be recomputed, but we may as well store it because
* it will come for free due to alignment considerations.
*/
typedef struct xl_heap_header
{
uint16 t_infomask2;
uint16 t_infomask;
uint8 t_hoff;
} xl_heap_header;
I find it hard to see how tacking t_hoff onto what would have been a
4-byte struct is "free". Maybe sometime in the dim past there was
another field in this struct? (But I checked back as far as 7.4
without finding one.)
I don't particularly want to remove the field, but we ought to
change or remove the comment.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2020-07-21 19:16:06 | v13 planner ERROR: could not determine which collation to use for string comparison |
Previous Message | Andres Freund | 2020-07-21 18:02:11 | Re: xl_heap_header alignment? |