On 2014-02-17 14:06:43 -0500, Robert Haas wrote: > On Mon, Feb 17, 2014 at 1:55 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2014-02-17 13:49:01 -0500, Robert Haas wrote: > > It's just a write barrier which evaluates to a pure compiler barrier on > > x86 anyway? > > And it's in a loop that's only entered when the kernel is entered anyway > > to wake up the other backend. > > > > What should that affect significantly? > > On x86, presumably nothing. On other architectures, I don't know what > the impact is, but I don't accept a hand-wavy assertion that there > shouldn't be any as evidence that there won't be.
Directly afterwards there's a syscall that needs to do internal locking (because it's essentially doing IPC). Which combined certainly is much more expensive then a write barrier. And any !x86 architecture that has more heavyweight write barriers really *needs* a barrier there since you only need more heavywheight write barriers if the architecture doesn't guarantee total store order. This isn't a performance optimization, it's correctness. What's the way to resolve this then? I don't have access to any big !x86 machines. 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
