Re: better atomics - v0.2

On Tue, Nov 19, 2013 at 9:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On point #2, I don't personally know of any systems that I care about
>> where inlining isn't supported. However, we've gone to quite a bit of
>> trouble relatively recently to keep things working for platforms where
>> that is the case, so I feel the need for an obligatory disclaimer: I
>> will not commit any patch that moves the wood in that area unless
>> there is massive consensus that this is an acceptable way forward.
>> Similarly for point #3: Heikki not long ago went to the trouble of
>> unbreaking --disable-spinlocks, which suggests that there is at least
>> some interest in continuing to be able to run in that mode. I'm
>> perfectly OK with the decision that we don't care about that any more,
>> but I will not be the one to make that decision, and I think it
>> requires a greater-than-normal level of consensus.
>
> Hm. Now that I think about it, isn't Peter proposing to break systems
> without working "inline" over here?
> http://www.postgresql.org/message-id/1384257026.8059.5.camel@vanquo.pezone.net
>
> Maybe that patch needs a bit more discussion. I tend to agree that
> significantly moving our portability goalposts shouldn't be undertaken
> lightly. On the other hand, it is 2013, and so it seems not unreasonable
> to reconsider choices last made more than a dozen years ago.

Sure. inline isn't C89, and to date, we've been quite rigorous about
enforcing C89-compliance, so I'm going to try not to be the guy that
casually breaks that. On the other hand, I haven't personally seen
any systems that don't have inline in a very long time. The first
systems I did development on were not even C89; they were K&R, and you
had to use old-style function declarations. It's probably safe to say
that they didn't support inline, either, though I don't recall trying
it. But the last time I used a system like that was probably in the
early nineties, and it's been a long time since then. However, I
upgrade my hardware about every 2 years, so I'm not the best guy to
say what the oldest stuff people still care about is.

> Here's an idea that might serve as a useful touchstone for making choices:
> compiler inadequacies are easier to fix than hardware/OS inadequacies.
> Even a dozen years ago, people could get gcc running on any platform of
> interest, and I seriously doubt that's less true today than back then.
> So if anyone complains "my compiler doesn't support 'const'", we could
> reasonably reply "so install gcc". On the other hand, if the complaint is
> "my hardware doesn't support 64-bit CAS", it's not reasonable to tell them
> to buy a new server.

I generally agree with that principle, but I'd offer the caveat that
some people do still have valid reasons for wanting to use non-GCC
compilers. I have been told that HP's aCC produces better results on
Itanium than gcc, for example. Still, I think we could probably make
a list of no more than half-a-dozen compilers that we really care
about - the popular open source ones (is there anything we need to
care about other than gcc and clang?) and the ones supported by large
vendors (IBM's ICC and HP's aCC being the ones that I know about) and
adopt features that are supported by everything on that list.

Another point is that, some releases ago, we began requiring working
64-bit arithmetic as per commit
d15cb38dec01fcc8d882706a3fa493517597c76b. We might want to go through
our list of nominally-supported platforms and see whether any of them
would fail to compile for that reason. Based on the commit message
for the aforementioned commit, such platforms haven't been viable for
PostgreSQL since 8.3, so we're not losing anything by canning them.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company