Re: removing old ports and architectures

On 2013-10-16 14:20:58 -0400, Robert Haas wrote:
> > I think if somebody wants to have it supported they need to provide a
> > buildfarm member and probably a bit of help. Doing any change in this
> > area for a platform that nobody has access to in any way seems
> > pointless because it will be broken anyway.
>
> I don't agree with that policy. Sure, 97% of our users are probably
> running Linux, Windows, MacOS X, or one of the fairly-popular BSD
> variants. But I think a part of the appeal of PostgreSQL is that it is
> cross-platform, and doesn't require a lot of special hardware support,
> and I'm loathe to give that up. It's one thing to say, gee, we don't
> know whether this is actually going to compile and work on your
> platform, because it's not tested. It's quite something else to say,
> anything that's not on this short list of supported platforms has zero
> chance of working without jumping through major hoops.

Well, I am not advocating to break platforms just because they are not
on the buildfarm, but I don't see how we can introduce new facilities
that require platform support if we don't have any way to test them on
some platforms.

> Commit b8ed4cc9627de437e5eafdb81631a0d0f063abb3, from April of this
> year, updated our support for --disable-spinlocks. Spinlocks are a
> far more basic facility than the sorts of advanced primitives we're
> talking about requiring here. If we're going to support compiling
> under --disable-spinlocks, then we certainly can't rely on this more
> advanced stuff always being present. Even if we get rid of that, it's
> throwing up one more barrier in front of people who want to get
> PostgreSQL running on a non-mainstream architecture. I've spent
> enough time over the years working on odd hardware to have sympathy
> for people who want to compile stuff there and have it work, or at
> least work after some non-huge amount of hacking.

I think by using architecture independent, compiler provided intrinsics
we take care of that for most non-mainstream platforms. Just about
everything even remotely new that is/will be out there is/will be using gcc
or something compatible to it (e.g. llvm). Those provide the __sync_*
intrinsics we'd wrap.
That's incidentally why I am advocating including pg_atomic_clear and
pg_atomic_test_set in the set of supported atomics. With those porting
to a new platform will often require exactly zero changes since
spinlocks will just use them.

> > We're talking about CPUs with mostly less than 100MHZ here, mostly with
> > directly soldered RAM in the one digit MB range. I really don't think
> > there's a usecase for running PG on them. And I doubt it still works on
> > many of the architectures we advocate.
>
> If stuff is completely ancient and obsolete, I think it's fine to kill
> it; it probably doesn't work anyway, and nobody's likely to try. But
> I think a lot of the stuff you're talking about is not in that
> category.

Which? We only seem to disagree about M32R and m68k, right? I've
recanted mips and superh days ago ;).
If you find alpha important, that's fine, that's supported by gcc. I
just doubt we'll get it even remotely right without tests...

> >> I'm also not sure that this is dead enough to kill.
> >>
> >> > - M32R (no userspace CAS afaics)
> >>
> >> Support was added for this in 8.3 and it doesn't seem to be particularly dead.
> >
> > It's not? All I've read seems to point into a different direction.
> >
> > The newest supported CPU seems to be
> > http://www.renesas.com/products/mpumcu/m32r/m32r_ecu/32196/index.jsp
> > sporting a whopping 1024Kb of programmable RAM and only single precision
> > FPU.
>
> Well, so, they're an embedded chip. Yes, it's low spec. But then
> why'd somebody bother adding spinlock support for it in 2007? It's
> not as if that was a high-end chip *then* either.

Well, 2007 postgres was still smaller. I think these days the postgres
binary alone wouldn't fit onto the executable memory of such devices. A pretty
minimal, stripped postgres (CFLAGS=-Os --without-zlib
--without-readline) weighs 4.5MB these days. 8.3 still was 2.6MB.

Not to even talk about our runtime memory requirements which since have
gone up noticeably.

> It's hard to say where to draw the line here. I don't want the
> illusion of support for platforms that don't in fact have a prayer of
> working to prevent us from making needed improvements. On the other
> hand, I also don't want to blithely rip out support for architectures
> that people may well still be using and where, in some cases, people
> have gone out of their way to add that support. If we get to the
> point where some relatively-obscure architecture is the only thing
> standing between us and improvement X, then we can weigh those things
> against each other and decide. But I don't really want to go rip out
> support for half-a-dozen semi-supported architectures without some
> clear goal in mind. That just doesn't seem friendly.

Well, I only started to look at this somewhat seriously because more and
more people in the last year or so, both onlist and towards 2ndq were
complaining about massive spinlock contention (up to 97% spent in
s_lock) on somewhat bigger machines. The primary offender in many
workloads is the lwlock internal spinlock, quite often for LW_SHARED
acquisition where we shouldn't need to block.

That triggered developing the wait-free LW_SHARED patch
http://www.postgresql.org/message-id/20130926225545.GB26663@awork2.anarazel.de
which indeed shows quite some promise. Unfortunately it pretty
fundamentally requires compare_swap and fetch_add. Now we could just
implement lwlocks in two pretty much independent ways, but that seems to
be pretty bad from a maintainability POV.

The next big thing after that is getting rid of spinlocks around buffer
pinning (and by that in buffer hdr locking). That would end up in quite
some #ifdef's sprinkled around.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services