On 2014-09-09 17:30:44 -0400, Robert Haas wrote: > On Tue, Sep 9, 2014 at 5:09 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2014-09-09 13:52:40 -0400, Robert Haas wrote: > >> I had forgotten that it needed an update. Thanks for the reminder. > >> Here's v2. > > > > I've attached a incremental patch fixing minor gripes. Other than that I > > think you can go ahead with this once the buildfarm accepts the sparc > > fixes (man, those machines are slow. spoonbill apparently takes ~5h for > > one run). > > > > I've done a read through s_lock.h and the only remaining potential issue > > that I see is that I have no idea if unixware's tas() is actually a safe > > compiler barrier (it is a memory barrier). And I really, really can't > > make myself care. > > * It is the responsibility of these macros to make sure that the compiler > * does not re-order accesses to shared memory to precede the actual lock > - * acquisition, or follow the lock release. Prior to PostgreSQL 9.5, this > - * was the caller's responsibility, which meant that callers had to use > + * acquisition, or following the lock release. Prior to PostgreSQL 9.5, > + * this was the caller's responsibility, which meant that callers had to use > > AFAICS my version is right and your version is grammatically > incorrect. "re-order to proceed or follow" uses the same verb tense in > both branches of the or; "re-order to proceed or following" does not.
Wasn't sure about that one. It read oddly to me, but then I'm not a native speaker. And won't read the sentence often ;) > I agree that if there are problems on UnixWare, we can let anyone who > cares about UnixWare submit a patch to fix them. Ok. 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
