Re: Spinlocks and compiler/memory barriers

Robert Haas <robertmhaas(at)gmail(dot)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.

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.

regards, tom lane