Re: better atomics - v0.5

On Mon, Jun 30, 2014 at 07:44:47PM +0200, Andres Freund wrote:
> On 2014-06-30 13:15:23 -0400, Robert Haas wrote:
> > I'm personally not convinced that we're approaching this topic in the
> > right way. I'm not convinced that it's at all reasonable to try to
> > emulate atomics on platforms that don't have them. I would punt the
> > problem into the next layer and force things like lwlock.c to have
> > fallback implementations at that level that don't require atomics, and
> > remove those fallback implementations if and when we move the
> > goalposts so that all supported platforms must have working atomics
> > implementations.
>
> If we're requiring a atomics-less implementation for lwlock.c,
> bufmgr. et al. I'll stop working on those features (and by extension on
> atomics). It's an utter waste of resources and maintainability trying to
> maintain parallel high level locking algorithms in several pieces of the
> codebase. The nonatomic versions will stagnate and won't actually work
> under load. I'd rather spend my time on something useful. The spinlock
> based atomics emulation is *small*. It's easy to reason about
> correctness there.
>
> If we're going that way, we've made a couple of absolute fringe
> platforms hold postgres, as actually used in reality, hostage. I think
> that's insane.

I agree completely.

> > If this patch goes in
> > the way it's written right now, then I think it basically amounts to
> > throwing platforms that don't have working atomics emulation under the
> > bus

> >, and my vote is that if we're going to do that, we should do it
> > explicitly: sorry, we now only support platforms with working atomics.
> > You don't have any, so you can't run PostgreSQL. Have a nice day.

I might share that view if a platform faced a huge and easily-seen performance
regression, say a 40% regression to 5-client performance. I don't expect the
shortfall to reach that ballpark for any atomics-exploiting algorithm we'll
adopt, and your (Andres's) latest measurements corroborate that.

--
Noah Misch
EnterpriseDB http://www.enterprisedb.com