On Tue, Jul 1, 2014 at 2:52 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> The bottom line is that I love supporting obscure platforms as much as >> anyone here, and several other committers are already telling me that >> I love it too much. We've got to draw the line somewhere, and I think >> refusing to ship newly-written code that we have exactly zero means of >> testing is a pretty good place to draw it. > > I'm good with the concept of expecting anyone who complains about lack > of support for $platform to provide resources for testing/debugging PG > on that platform; and that pending arrival of such resources it's okay > to consider the platform desupported. What concerns me here is what > level of support we could provide even with adequate resources. That > is, are we going to be buying into a scenario where platforms with poor > atomics support take a significant performance hit compared to the > current state of affairs? I don't think that would be good. > > Another way of framing the problem is in response to Andres' upthread > comment that relying on emulated atomics makes things much easier to > reason about. That may be true as far as correctness is concerned but > it's patently false for reasoning about performance. This ties into > Robert's worry about how many different hardware performance profiles > we're going to have to concern ourselves with.
I have to admit that my concerns in that area were ameliorated to a significant degree by the performance results that Andres posted yesterday. On top of the atomics patch (which is not this thread), he's got a rewritten lwlock patch that uses those atomics. His testing showed that, even when that patch uses the atomics emulation layer instead of real atomics, it's still better than the status quo. Maybe that won't be true for every patch that uses atomics, but it's certainly good as far as it goes. But I think the issue on this sub-thread is a different one altogether: in studying s_lock.h, Andres found clear evidence that the ARMv5 and Sun Studio spinlock implementations are in fact *buggy*. Even if the programmer uses volatile pointers until they turn blue in the face, nothing in that patch prevents the CPU from changing the apparent order of execution such that instructions within the spinlock-protected critical section appear to execute after lock release. That is no good. It means that if somebody runs PostgreSQL on those platforms and tries to do non-trivial things with it, it's probably going to break. Now, if we want, we can simply ignore that problem. No actual users have complained about it, and it's not entirely outside the bounds of plausibility that Andres is wrong, and those implementations are not buggy after all. But I don't think he's wrong. If we assume he's right, then we've got two choices: we can either blindly install fixes for those platforms that we can't test, or we can drop support. > Basically the future that concerns me is that we perform well on x86_64 > hardware (which I believe is pretty much all that any active developers > are using) and poorly on other hardware. I don't want to end up there, > but I think the current direction of this patch pretty much guarantees > that outcome. I think this concern is more germane to the atomics patch than what we're talking about here, because what we're talking about here, at the moment, is either attempting to repair, or just rip out completely, S_UNLOCK() implementations that appear to be buggy. I have access to several PPC64 systems, use them regularly for benchmarking and performance-testing, and can provide access to one of those to others who may need it for testing. For that reason, I think at least x64/amd64 and PPC64 will get tested regularly, at least as long as IBM keeps that hardware on loan to us. I previously had access to an Itanium server and used that for a lot of testing during the 9.2 cycle, but that eventually went away. I think it would be awfully nice if some hardware vendor (or interested community member) could provide us with access to some top-quality SPARC, ARM, and maybe zSeries machines for testing, but nobody's offered that I know of. We can't test hardware we don't have. Despite my concerns about keeping the list of supported atomics short, and I do have concerns in that area, I'm not really sure that we have much choice but to go in that direction. We can't accept a >5x performance hit in the name of portability, and that's literally what we're talking about in some cases. I definitely want to think carefully about how we proceed in this area but doing nothing doesn't seem like an option. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
