From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Ensuring hash tuples are properly maxaligned |
Date: | 2018-01-03 01:43:55 |
Message-ID: | 20180103014355.52an4fgwigdzhzxh@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-01-02 20:40:50 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2018-01-03 14:29:15 +1300, Thomas Munro wrote:
> >> On Wed, Jan 3, 2018 at 2:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>> Andres Freund <andres(at)anarazel(dot)de> writes:
> >>> But note that dsa_pointer can be wider than a regular pointer on
> >>> platforms without atomics support.
>
> >>> Hm. I did not get that impression from the comments in dsa.h,
> >>> but if it's true then this approach won't work --- and indeed the
> >>> hash code would be actively broken in such a case, so it's a problem
> >>> we must fix.
>
> >> Maybe Andres is thinking of dsa_pointer_atomic? dsa_pointer is
> >> normally the size of a pointer (well, really, the size of size_t),
> >> though it could be *narrower* if you don't have atomics or ask for it
> >> with USE_SMALL_DSA_POINTER
>
> > Yep, I was.
>
> OK, then there's not a live bug, but I'm a bit tempted to get rid of
> the data[] member anyway. It's not clear to me now that keeping it
> results in net cleaner code. Thoughts?
I like that plan. I don't think the data field buys us anything, and I
personally in most cases find "fully manual" alignment code easier to
reason about than fiddling with padding fields.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-01-03 01:49:17 | Re: Ensuring hash tuples are properly maxaligned |
Previous Message | Gerdan Rezende dos Santos | 2018-01-03 01:41:02 | Re: CFM for January commitfest? |