On Thu, Jun 19, 2014 at 10:43 AM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Thu, Jun 19, 2014 at 7:07 AM, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote:
>> Let's not pretend to support platforms we have no practical way of
>> verifying.
>
> This is key. The buildfarm defines the set of platforms we support.
This criterion has been proposed before, but I'm not sure I really
agree with it. If having code around that targets obscure platforms
is hindering the development of new features, then that's a reason to
get rid of it. If we're pretty sure it's useless and doesn't work, so
is that. But if it just hasn't been tested lately, I don't personally
think that's a sufficient reason to excise it. Telling people that
they can't have even the most minimal platform support code in
PostgreSQL unless they're willing to contribute and maintain a BF VM
indefinitely is not very friendly. Of course, the risk of their
platform getting broken is higher if they don't, but that's different
than making it a hard requirement. We should be looking at ways to
make it easier not harder for people who don't yet run PostgreSQL to
start doing so. We are an open source community; we should try to be,
as far as possible, open.
But I think this is all a bit off-topic for this thread. Andres has
already implemented a fallback for people who haven't got CAS and
fetch-and-add on their platform, so whether or not we deprecate some
more platforms has no bearing at all on this patch. The question that
needs to be resolved in order to move forward here is this: Consider
the set of platforms we support, ignoring any that don't have
spinlocks. Do any of them have only one of fetch-and-add, or do they
all have both or neither? If it's the latter, then we're talking
about moving from a two-tiered system that looks like this:
1. No spinlocks.
2. Spinlocks.
...to a three-tiered system that looks like this:
1. No atomics at all.
2. Spinlocks but nothing else.
3. Spinlocks, CAS, and fetch-and-add.
I think that's eminently reasonable from a code maintenance and
developer testing perspective. It sounds like all common systems and
architectures would fall in category 3, meaning that people wouldn't
have to worry about (just for example) significant differences between
the atomic ops supported on Intel vs. PPC. For older or more obscure
platforms, categories 2 and 1 would still be there when needed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
