9.4 broken on alpha

On 08/25/2015 06:16 AM, Christoph Berg wrote:

Hi,

From the Debian ports buildd:

https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=alpha&ver=9.4.4-1&stamp=1434132509

make[5]: Entering directory '/«PKGBUILDDIR»/build/src/backend/postmaster'
[...]
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 -Wformat -Werror=format-security -I/usr/include/mit-krb5 -fPIC -pie -DLINUX_OOM_SCORE_ADJ=0 -I../../../src/include -I/«PKGBUILDDIR»/build/../src/include -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/tcl8.6 -c -o bgworker.o /«PKGBUILDDIR»/build/../src/backend/postmaster/bgworker.c
/tmp/cc4j88on.s: Assembler messages:
/tmp/cc4j88on.s:952: Error: unknown opcode `rmb'
as: BFD (GNU Binutils for Debian) 2.25 internal error, aborting at ../../gas/write.c line 603 in size_seg

as: Please report this bug.

<builtin>: recipe for target 'bgworker.o' failed
make[5]: *** [bgworker.o] Error 1

needs a buildfarm animal. If we had one we'd presumably have caught this
much earlier.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-08-25 08:29:18 -0400, Andrew Dunstan wrote:

needs a buildfarm animal. If we had one we'd presumably have caught this
much earlier.

On the other hand, we dropped alpha support in 9.5, ...

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 08/25/2015 08:30 AM, Andres Freund wrote:

On 2015-08-25 08:29:18 -0400, Andrew Dunstan wrote:

needs a buildfarm animal. If we had one we'd presumably have caught this
much earlier.

On the other hand, we dropped alpha support in 9.5, ...

Oh, I missed that. Sorry for the noise.

cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-08-25 08:57, Andrew Dunstan wrote:

On 08/25/2015 08:30 AM, Andres Freund wrote:

On 2015-08-25 08:29:18 -0400, Andrew Dunstan wrote:

needs a buildfarm animal. If we had one we'd presumably have caught this
much earlier.

On the other hand, we dropped alpha support in 9.5, ...

Oh, I missed that. Sorry for the noise.

I've been meaning to report this myself.

In the 4 years that that particular line has been there, not once had
anyone else run into it on Gentoo until a couple months ago.

And it isn't a case of end users missing it as we have arch testers
that test packages before marking them suitable for public consumption.

Alpha is one of the arches.

As for the dropped support, has the Alpha specific code been ripped
out? Would it still presumably run on Alpha?

Aaron W. Swenson wrote:

I've been meaning to report this myself.

In the 4 years that that particular line has been there, not once had
anyone else run into it on Gentoo until a couple months ago.

And it isn't a case of end users missing it as we have arch testers
that test packages before marking them suitable for public consumption.

Alpha is one of the arches.

This means that not once has anybody compiled in an Alpha in 4 years.

As for the dropped support, has the Alpha specific code been ripped
out? Would it still presumably run on Alpha?

Yes, code has been ripped out. I would assume that it doesn't build at
all anymore, but maybe what happens is you get spinlocks emulated with
semaphores and it's only horribly slow. See
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a6d488cb538c8761658f0f7edfc40cecc8c29f2d

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Aaron W. Swenson wrote:

In the 4 years that that particular line has been there, not once had
anyone else run into it on Gentoo until a couple months ago.
And it isn't a case of end users missing it as we have arch testers
that test packages before marking them suitable for public consumption.
Alpha is one of the arches.

This means that not once has anybody compiled in an Alpha in 4 years.

Well, strictly speaking, there were no uses of pg_read_barrier until 9.4.
However, pg_write_barrier (which used "wmb") was in use since 9.2; so
unless you're claiming your assembler knows wmb but not rmb, the code's
failed to compile for Alpha since 9.2.

As for the dropped support, has the Alpha specific code been ripped
out? Would it still presumably run on Alpha?

Yes, code has been ripped out. I would assume that it doesn't build at
all anymore, but maybe what happens is you get spinlocks emulated with
semaphores and it's only horribly slow.

The whole business about laxer-than-average memory coherency gives me the
willies, though. It's fairly likely that PG has never worked right on
multi-CPU Alphas.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-08-25 15:43:12 -0400, Aaron W. Swenson wrote:

As for the dropped support, has the Alpha specific code been ripped
out? Would it still presumably run on Alpha?

I'm pretty sure that postgres hasn't run correctly under concurrency on
alpha for a long while. The lax cache coherency makes developing
concurrent code hard. Since there are rarely, if ever, people testing
postgres on alpha under load it's nigh on impossible to verify anything.

Having to adhere to a more complicated memory model than for any other
architecture isn't worth it, since there barely are users.

Greetings,

Andres Freund

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Aaron W. Swenson wrote:

In the 4 years that that particular line has been there, not once had
anyone else run into it on Gentoo until a couple months ago.
And it isn't a case of end users missing it as we have arch testers
that test packages before marking them suitable for public consumption.
Alpha is one of the arches.

This means that not once has anybody compiled in an Alpha in 4 years.

Well, strictly speaking, there were no uses of pg_read_barrier until 9.4.
However, pg_write_barrier (which used "wmb") was in use since 9.2; so
unless you're claiming your assembler knows wmb but not rmb, the code's
failed to compile for Alpha since 9.2.

Actually according to this
http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f98/doc/alpha-asm.pdf
there is a wmb instruction but there is no rmb.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Tom Lane wrote:

Well, strictly speaking, there were no uses of pg_read_barrier until 9.4.
However, pg_write_barrier (which used "wmb") was in use since 9.2; so
unless you're claiming your assembler knows wmb but not rmb, the code's
failed to compile for Alpha since 9.2.

Actually according to this
http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f98/doc/alpha-asm.pdf
there is a wmb instruction but there is no rmb.

Oh really? If rmb were a figment of someone's imagination, it would
explain the build failure (although not why nobody's reported it till
now).

It'd be easy enough to s/rmb/mb/ in 9.4 ... but not sure it's worth
the trouble, since we're desupporting Alpha as of 9.5 anyway. If the
effective desupport date is 9.4 instead, how much difference does that
make?

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Aug 25, 2015 at 06:09:17PM -0400, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Tom Lane wrote:

Well, strictly speaking, there were no uses of pg_read_barrier until 9.4.
However, pg_write_barrier (which used "wmb") was in use since 9.2; so
unless you're claiming your assembler knows wmb but not rmb, the code's
failed to compile for Alpha since 9.2.

Actually according to this
http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15213-f98/doc/alpha-asm.pdf
there is a wmb instruction but there is no rmb.

Exactly, as I had explained in the Debian bug report [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756368 over a year
ago.

Oh really? If rmb were a figment of someone's imagination, it would
explain the build failure (although not why nobody's reported it till
now).

I reported the failure to build on Alpha, with an explanation and a
patch to fix it, to the Debian package maintainers over a year ago,
and within about of a month of version 9.4 being uploaded to Debian.

My recollection is that prior versions (9.2 and 9.3) compiled on
Alpha so the use of the wrong barrier, and the fix, was in fact
reported in a timely fashion following the first reasonable chance to
observe the problem.

It has been built and running at Debian-Ports for over a year now as
I uploaded the fixed version to the Alpha unreleased distribution.

It'd be easy enough to s/rmb/mb/ in 9.4 ... but not sure it's worth
the trouble, since we're desupporting Alpha as of 9.5 anyway.

That is disappointing to hear. Why is that? It is still in use on
Alpha. What is the maintenance load for keeping the Alpha arch
specific code?

If the effective desupport date is 9.4 instead,

It's not. The fixed and built 9.4 version was uploaded to Debian-Ports
Alpha (in the unreleased distribution) and has been in use for over a
year.

Regards,
Michael.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756368

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Michael Cree wrote:

On Tue, Aug 25, 2015 at 06:09:17PM -0400, Tom Lane wrote:

Oh really? If rmb were a figment of someone's imagination, it would
explain the build failure (although not why nobody's reported it till
now).

I reported the failure to build on Alpha, with an explanation and a
patch to fix it, to the Debian package maintainers over a year ago,
and within about of a month of version 9.4 being uploaded to Debian.

It's a pretty disappointing packaging process failure that the bug
report wasn't sent to upstream immediately, rather than waiting for a
whole year. That would have made a lot less likely that the removal of
the port would have passed muster in the first place. Supposedly we
were only removing stuff that was pretty clearly dead.

It has been built and running at Debian-Ports for over a year now as
I uploaded the fixed version to the Alpha unreleased distribution.

Has this been battle-tested under high load in multi-core servers?
Because based on other comments in this and other threads, it seems
likely that the port is subtly broken.

It'd be easy enough to s/rmb/mb/ in 9.4 ... but not sure it's worth
the trouble, since we're desupporting Alpha as of 9.5 anyway.

That is disappointing to hear. Why is that? It is still in use on
Alpha. What is the maintenance load for keeping the Alpha arch
specific code?

The amount of code that was removed by the commit isn't all that much:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a6d488cb538c8761658f0f7edfc40cecc8c29f2d
but there's been rather a lot of work after that to add support for
atomic primitives as well as barriers, which would presumably not
trivial to implement and test on Alpha. Someone would have to volunteer
to writing, testing and maintaining that code. A buildfarm machine
would be mandatory, too.

I'm under the impression that Alpha machines are no longer being built,
so I'm doubtful that this would be a good use of anybody's time.

If the effective desupport date is 9.4 instead,

It's not. The fixed and built 9.4 version was uploaded to Debian-Ports
Alpha (in the unreleased distribution) and has been in use for over a
year.

I think we could apply the bugfix to 9.4, but this doesn't help with
9.5.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Michael Cree <mcree@orcon.net.nz> writes:

On Tue, Aug 25, 2015 at 06:09:17PM -0400, Tom Lane wrote:

It'd be easy enough to s/rmb/mb/ in 9.4 ... but not sure it's worth
the trouble, since we're desupporting Alpha as of 9.5 anyway.

That is disappointing to hear. Why is that? It is still in use on
Alpha. What is the maintenance load for keeping the Alpha arch
specific code?

The core problem is that Alpha's unusually lax memory coherency model
creates design and testing problems we face with no other architecture.
We're not really excited about carrying that burden for a legacy
architecture that isn't competitive in the modern world. Even if we
were, it's completely impractical to maintain such an unusual port
when there is no representative of the architecture in our buildfarm
(http://buildfarm.postgresql.org/cgi-bin/show_status.pl). It's worth
pointing out that had there been one, we would have noticed the rmb
problem long before 9.4 ever shipped.

I do not know anything about the prevalence of multi-CPU Alpha machines.
If they're thin on the ground compared to single-CPU, maybe we could just
document that we only support the latter, and not worry too much about
the memory coherency issues. But in any case, without a commitment from
somebody to maintain an Alpha buildfarm member, we will absolutely not
consider reviving that port.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Michael Cree wrote:

That is disappointing to hear. Why is that? It is still in use on
Alpha. What is the maintenance load for keeping the Alpha arch
specific code?

The amount of code that was removed by the commit isn't all that much:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a6d488cb538c8761658f0f7edfc40cecc8c29f2d
but there's been rather a lot of work after that to add support for
atomic primitives as well as barriers, which would presumably not
trivial to implement and test on Alpha. Someone would have to volunteer
to writing, testing and maintaining that code.

As far as that goes, we do have fallback atomics code that's supposed to
work on anything (and not be unusably slow). So in principle,
resurrecting the Alpha spinlock code ought to be enough to get back to the
previous level of support. Coding Alpha atomic primitives would likely
be worth doing, if there's somebody out there who's excited enough to take
it on; but that could happen later, and incrementally.

A buildfarm machine would be mandatory, too.

That, however, is not negotiable.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-08-26 12:49:46 -0400, Tom Lane wrote:

As far as that goes, we do have fallback atomics code that's supposed to
work on anything (and not be unusably slow). So in principle,
resurrecting the Alpha spinlock code ought to be enough to get back to the
previous level of support. Coding Alpha atomic primitives would likely
be worth doing, if there's somebody out there who's excited enough to take
it on; but that could happen later, and incrementally.

Actually, on linux and most other OSs it should just use the generic gcc
based implementation and be pretty close to optimal. The only thing it'd
need would be to define the memory barriers, so the fallback
implementation of those isn't used.

But I really strongly object to re-introducing alpha support. Having to
care about data dependency barriers is a huge pita, and it complicates
code for everyone. And we'd have to investigate a lot of code to
actually make it work reliably. For what benefit?

A buildfarm machine would be mandatory, too.

That, however, is not negotiable.

If we really were to re-introduce this we'd need an actual developer
machine to run tests against.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Andres Freund <andres@anarazel.de> writes:

But I really strongly object to re-introducing alpha support. Having to
care about data dependency barriers is a huge pita, and it complicates
code for everyone. And we'd have to investigate a lot of code to
actually make it work reliably. For what benefit?

I hear you, but that's only an issue for multi-CPU machines no? If we
just say "we doubt this works on multi-CPU Alphas, if it breaks you get to
keep both pieces", then we're basically at the same place we were before.

To be clear: I don't want to do the work you're speaking of, either.
But if we have people who were successfully using PG on Alphas before,
the coherency issues must not have been a problem for them. Can't we
just (continue to) ignore the issue?

If we really were to re-introduce this we'd need an actual developer
machine to run tests against.

I would certainly expect that we'd insist on active support from the Alpha
community; we're not going to continue to do this in an open-loop fashion.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Aug 26, 2015 at 12:49:46PM -0400, Tom Lane wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

A buildfarm machine would be mandatory, too.

That, however, is not negotiable.

Right. I think the still-open question around PostgreSQL on Alpha is whether
9.1 through 9.4 are meaningfully supported there. Step one for anyone
interested in Alpha support is to activate a buildfarm member covering that
range of versions. Without that, the PostgreSQL community is just listening
for bug fix contributions.

On Wed, Aug 26, 2015 at 01:34:38PM -0400, Tom Lane wrote:

Andres Freund <andres@anarazel.de> writes:

But I really strongly object to re-introducing alpha support. Having to
care about data dependency barriers is a huge pita, and it complicates
code for everyone. And we'd have to investigate a lot of code to
actually make it work reliably. For what benefit?

I hear you, but that's only an issue for multi-CPU machines no? If we
just say "we doubt this works on multi-CPU Alphas, if it breaks you get to
keep both pieces", then we're basically at the same place we were before.

To be clear: I don't want to do the work you're speaking of, either.
But if we have people who were successfully using PG on Alphas before,
the coherency issues must not have been a problem for them. Can't we
just (continue to) ignore the issue?

The landscape changed with the 9.5 cycle's push to use more lock-free
algorithms. Dropping Alpha support simplified review for those algorithms.
True, we could ignore Alpha for review purposes and accept unstudied damage to
reliability on Alpha. To some extent, that characterizes any platform whose
test reports don't reach us. It's different when we know Alpha has special
needs and we make changes in the area of those needs without even attempting
to meet them. We made a decision to instead break compatibility explicitly,
and I don't think this thread has impugned that decision.

As it is, we've implicitly prepared to ship Alpha-supporting PostgreSQL 9.4
until 2019, by which time the newest Alpha hardware will be 15 years old.
Computer museums would be our only audience for continued support. I do have
a sentimental weakness for computer museums, but not at the price of drag on
important performance work.

nm

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: Andrew Dunstan 2015-08-25 <55DC5F9E.60601@dunslane.net>

gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2 -Wformat -Werror=format-security -I/usr/include/mit-krb5 -fPIC -pie -DLINUX_OOM_SCORE_ADJ=0 -I../../../src/include -I/�PKGBUILDDIR�/build/../src/include -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/tcl8.6 -c -o bgworker.o /�PKGBUILDDIR�/build/../src/backend/postmaster/bgworker.c
/tmp/cc4j88on.s: Assembler messages:
/tmp/cc4j88on.s:952: Error: unknown opcode `rmb'
as: BFD (GNU Binutils for Debian) 2.25 internal error, aborting at ../../gas/write.c line 603 in size_seg

needs a buildfarm animal. If we had one we'd presumably have caught this
much earlier.

In the meantime, I've added this patch to the 9.4 Debian package, and
the build including check-world succeeds:

https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&amp;arch=alpha&amp;ver=9.4.4-2&amp;stamp=1440797195

It'd be nice if the patch could get applied to 9.4 and earlier.

Thanks,
Christoph
--
Senior Berater, Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB M�nchengladbach 12080, USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 M�nchengladbach
Gesch�ftsf�hrung: Dr. Michael Meskes, J�rg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970 87C6 4C5A 6BAB 12D2 A7AE

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Aug 26, 2015 at 09:19:09PM -0400, Noah Misch wrote:

As it is, we've implicitly prepared to ship Alpha-supporting
PostgreSQL 9.4 until 2019, by which time the newest Alpha hardware
will be 15 years old. Computer museums would be our only audience
for continued support. I do have a sentimental weakness for
computer museums, but not at the price of drag on important
performance work.

+1000

I think we need to take realistic stock of what we're doing and what
we should require.

At a minimum, we should de-support every platform on which literally
no new deployments will ever happen.

I'm looking specifically at you, HPUX, and I could make a pretty good
case for the idea that we can relegate 32-bit platforms to the ash
heap of history, at least on the server side.

Then, there's the question of rotating media. Given the givens, we
ought to be drawing up plans for the cases where we might consider
supporting them, but those would need to be zero-based plans, i.e. the
starting point would be that we don't support them, and arguments
would have to be made affirmatively to support them for some specific,
demonstrable use case.

Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2015-08-29 08:32:29 -0700, David Fetter wrote:

and I could make a pretty good
case for the idea that we can relegate 32-bit platforms to the ash
heap of history, at least on the server side.

Don't see the point, it doesn't cost us very much.

Then, there's the question of rotating media. Given the givens, we
ought to be drawing up plans for the cases where we might consider
supporting them, but those would need to be zero-based plans, i.e. the
starting point would be that we don't support them, and arguments
would have to be made affirmatively to support them for some specific,
demonstrable use case.

We don't particularly care either way, so I don't see why we'd add/drop
support for anything here.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers