Re: Include ppc64le build type for back branches

On Wed, Dec 9, 2015 at 2:54 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> With respect to this particular thing, it's hard for me to imagine
>> that anything will go wrong on ppcle that we wouldn't consider a
>> back-patchable fix, so there might be no harm in adjusting
>> config.guess and config.sub.
>
> FWIW, I also suspect that supporting ppc64le would not really take
> much more than updating config.guess/config.sub; there's no evidence
> in the git logs that we had to fix anything else in the newer branches.
>
> My concern here is about establishing project policy about whether
> we will or won't consider back-patching support for newer platforms.
> I think that the default answer should be "no", and I'd like to
> see us set down some rules about what it takes to override that.
>
> Obviously, setting up a buildfarm member helps a good deal. But
> is that sufficient, or necessary?

I would say it's necessary but not sufficient. The other criterion
I'd lay down is that you shouldn't need to really change anything in
the code except maybe to fix up s_lock.h breakage or some equally
minor wart. For example, suppose that somebody wanted a new platform
which works just like UNIX except that open() takes 4 arguments
instead of 3, and we've always got to pass 0 for the last one. Well,
even though that's minor and easily done, I'm not going to argue for
back-patching that to all supported branches. I don't think that
would be good material for a back-patch; the necessary changes could
flummox third-party code or just turn out to be buggy, and apparently
this new platform wasn't that important up until now, so whatever.

But I feel differently about this case because we basically already do
support the platform, or so it seems. We just didn't know we
supported it. Really, we expect our stuff to work anywhere that has a
reasonably UNIX-like environment and, hey, it'll even use atomics
automatically if it has a reasonably modern gcc. So, win. I don't
think that we really gain anything by refusing to admit that the
product works on a platform where it does work. We've put a lot of
effort into being portable and I don't think we should feel bad about
that. If we test PostgreSQL on a new platform and it works with no
problems (or only trivial adjustments that seem like good back-patch
candidates anyway), then I think it's fine to just say, yep, it works.
I don't think that sets a precedent that we'll be willing to accept
arbitrary changes in back-branches to make it work when it doesn't
already.

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