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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers