On 2015-01-14 17:46:39 -0500, Robert Haas wrote:
> On Wed, Jan 14, 2015 at 5:29 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > I think it's better than the alternatives:
> >
> > a) Don't support 64bit atomics on any 32bit platform. I think that'd be
> > sad because there's some places that could greatly benefit from being
> > able to read/store/manipulate e.g. LSNs atomically.
> > b) Double the size of 64bit atomics on 32bit platforms, and add
> > TYPEALIGN() to every access inside the atomics implementation.
> > c) Require 64 atomics to be aligned appropriately manually in every
> > place they're embedded. I think that's completely impractical.
> >
> > The only viable one imo is a)
>
> I can't really fault that reasoning, but if __attribute__((align))
> only works on some platforms, then you've got silent, subtle breakage
> on the ones where it doesn't.
The __attribute__((align()))'s are in compiler specific code sections
anyway - and there's asserts ensuring that the alignment is correct in
all routines where it matters (IIRC). Those are what caught the
problem. C.f.
http://archives.postgresql.org/message-id/20150108204635.GK6299%40alap3.anarazel.de
I think I'd for now simply not define pg_attribute_aligned() on
platforms where it's not supported, instead of defining it empty. If we
need a softer variant we can name it pg_attribute_aligned_if_possible or
something.
Sounds sane?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services