On 2014-02-17 14:06:43 -0500, Robert Haas wrote:
> On Mon, Feb 17, 2014 at 1:55 PM, Andres Freund <andres@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
