Re: better atomics - v0.5 - Mailing list pgsql-hackers

From Noah Misch
Subject Re: better atomics - v0.5
Date
Msg-id 20140701014626.GB1547033@tornado.leadboat.com
Whole thread Raw
In response to Re: better atomics - v0.5  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: John Klos
Date:
Subject: Re: PostgreSQL for VAX on NetBSD/OpenBSD
Next
From: Tom Lane
Date:
Subject: Re: PATCH: Allow empty targets in unaccent dictionary