On Wed, Jun 25, 2014 at 10:50:47AM -0700, Greg Stark wrote: > On Wed, Jun 25, 2014 at 10:17 AM, Robert Haas <robertmh...@gmail.com> wrote: > > Well, the fact that initdb didn't produce a working configuration and > > that make installcheck failed to work properly are bad. But, yeah, > > it's not totally broken. > > Yeah it seems to me that these kinds of autoconf and initdb tests > failing are different from a platform where the spinlock code doesn't > work. It's actually valuable to have a platform where people routinely > trigger those configuration values. If they're broken there's not much > value in carrying them.
Well, I have to ask this question: why should there be any "vax-specific code"? What facilities beyond what POSIX with the threading extensions offers on a modern system do you really need? Why? It seems to me that NetBSD/vax is a very good platform for testing one's assumptions about whether one's code is truly portable -- because it is a moderately weird architecture, with some resource constraints, but with a modern kernel and runtime offering everything you'd get from a software point of view on any other platform. Except, of course, for IEEE floating point, because the VAX's floating point unit simply does not provide that. But if other tests fail on the VAX or one's source tree is littered with any other kind of VAX-specific code or special cases for VAX, I would submit that this suggests one's code has fairly serious architectual or implementation discipline issues. Thor -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
