On 2018-01-02 20:40:50 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.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@sss.pgh.pa.us> wrote:
> >>> Andres Freund <andres@anarazel.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
