Robert Haas <[email protected]> writes: > On Wed, Jul 17, 2013 at 6:39 PM, Tom Lane <[email protected]> wrote: >> On HPPA, implement pg_memory_barrier() as pg_compiler_barrier(), which >> should be correct since this arch doesn't do memory access reordering, >> and is anyway better than the completely-nonfunctional-on-this-arch >> dummy_spinlock code. (But note this patch only fixes things for gcc, >> not for builds with HP's compiler.)
> According to http://en.wikipedia.org/wiki/Memory_ordering, PA-RISC has > weak memory ordering. > So either this commit is wrong, or one of those things is wrong. If this commit is wrong, then our HPPA spinlock code has been wrong for circa fifteen years. It's entirely possible that that's true and nobody has noticed (perhaps for lack of any multiprocessor HPPA systems to test on?). Still, that would make it roughly six orders of magnitude less broken than "can't get through bootstrap", which is where we were this morning. As I hope my commit comment made clear, this is the beginning of making barrier.h trustworthy, not the end. regards, tom lane -- Sent via pgsql-committers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
