>> That's all I have time for tonight. Is there an easier way to run a
>> testsuite?
>
> I think you're doing it right, but apparently configure is
> mis-identifying which flags are needed for thread-safety on your
> platform. It's possible configuring with --disable-thread-safety
> would help, or you could manually edit the Makefile.
I'll play with it some more in a little bit. This is why I tend to trust
the pkgsrc framework - it just works.
> 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.
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.
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.
Thanks,
John