On Wed, Jun 25, 2014 at 1:05 PM, John Klos <john@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
