On Wed, Jun 25, 2014 at 1:05 PM, John Klos <j...@ziaspace.com> wrote: >> In any case I'm coming to the conclusion that there's little point in >> us keeping the VAX-specific code in our source tree, because in fact, >> this port is broken and doesn't work. Based on your results thus far, >> I doubt that it would be a huge amount of work to fix that, but unless >> somebody from the VAX community wants to volunteer to be a PostgreSQL >> maintainer for that platform, straighten out the things that have >> gotten broken since this port was originally added, and keep it >> working on an ongoing basis, it's probably not going to happen. > > While I wouldn't be surprised if you remove the VAX code because not many > people are going to be running PostgreSQL, I'd disagree with the assessment > that this port is broken. It compiles, it initializes databases, it runs, et > cetera, albeit not with the default postgresql.conf.
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. > I'm actually rather impressed at how well PostgreSQL can be adjusted to > lower memory systems. I deploy a lot of embedded systems with 128 megs (a > lot for an embedded system, but nothing compared with what everyone else > assumes), so I'll be checking out PostgreSQL for other uses. I agree, that's cool. > NetBSD's VAX port does lots to help ensure code portability and code > correctness, so it's not going anywhere any time soon. It certainly is a > good sign that PostgreSQL can run on a VAX with only 20 MB or so of resident > memory. Yeah! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers