On 2015-01-14 17:46:39 -0500, Robert Haas wrote: > On Wed, Jan 14, 2015 at 5:29 PM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
