Just some notes, before I forget them again. On 2013-09-23 11:50:05 -0400, Robert Haas wrote: > On Fri, Sep 20, 2013 at 11:11 AM, Andres Freund <and...@2ndquadrant.com> > wrote: > > On 2013-09-20 16:47:24 +0200, Andres Freund wrote: > >> I think we should go through the various implementations and make sure > >> they are actual compiler barriers and then change the documented policy. > > > > From a quick look > > * S_UNLOCK for PPC isn't a compiler barrier > > * S_UNLOCK for MIPS isn't a compiler barrier
Needs memory clobber looks easy enough given only gcc seems to be supported. > > * I don't know enough about unixware (do we still support that as a > > platform even) to judge Looks like another thing to remove? > > * PA-RISCs tas() might not be a compiler barrier for !GCC > > * PA-RISCs S_UNLOCK might not be a compiler barrier http://h21007.www2.hp.com/portal/download/files/unprot/ddk/mem_ordering_pa_ia.pdf _MF(); seems to work on both PA-RISC and itanic. > > * HP-UX !GCC might not The document linked from the source code explains how to implement it: http://h21007.www2.hp.com/portal/download/files/unprot/itanium/spinlocks.pdf #define COMP_FENCE _Asm_fence(_UP_MEM_FENCE|_DOWN_MEM_FENCE) > > * Generic S_UNLOCK *NOT* necessarily a compiler barrier. Not sure how to handle that one. 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
