On Thu, Oct 17, 2013 at 3:10 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Thu, Oct 17, 2013 at 12:22 AM, Noah Misch <n...@leadboat.com> wrote: >> Removing support for alpha is a different animal compared to removing support >> for non-gcc MIPS and most of the others in your list. A hacker wishing to >> restore support for another MIPS compiler would fill in the assembly code >> blanks, probably using code right out of an architecture manual. A hacker >> wishing to restore support for alpha would find himself auditing every >> lock-impoverished algorithm in the backend. > > I had much the same thought last night. So I reverse my vote on > Alpha: let's drop it. I had thought that perhaps there'd be some > value in keeping it to force ourselves to consider what will happen > under the weakest generally-understood memory model, but in fact > that's probably a doomed effort without having the hardware available > to test the code. As you say, any future atomics support for such a > platform will be a major undertaking.
FWIW, I think that if we approach coding lock free algorithms correctly - i.e. "which memory barriers can we avoid while being safe", instead of "which memory barriers we need to add to become safe" - then supporting Alpha isn't a huge amount of extra work. We only need a couple of extra barriers after atomic reads where I think we should have a comment anyway explaining that we don't need a read barrier because a data dependency provides ordering. In general I agree that we are unlikely to provide a bug free result without a build farm animal, so I'm ±0 on removing support. We can try to support, but we are unlikely to succeed. I also find it unlikely that anyone will create a new architecture with a similarly loose memory model. The experience with Alpha and other microprocessors shows that the extra hardware needed for fast and strong memory ordering guarantees more than pays for itself in performance. Regards, Ants Aasma -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers