PostgreSQL for VAX on NetBSD/OpenBSD
Hello VAX Enthusiasts:
PostgreSQL currently has some very minimal code to support the VAX
architecture. We have never supported OpenVMS, so this code would
only be used if someone were to compile PostgreSQL for VAX on an
operating system that we *do* support, such as NetBSD or OpenBSD.
However, we don't know of anyone who has tried to do this in a very
long time, and are therefore considering removing the remaining
support for the VAX platform. Has anyone tried to build PostgreSQL
for VAX lately? If so, did it compile? Did you have to use
--disable-spinlocks to get it to compile? If it did compile, can you
actually run it, and does it pass the regression tests and work as
expected? Would you be willing to work with the PostgreSQL to ensure
continuing support for this platform, or does that seem not worthwhile
for whatever reason?
Thanks,
--
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
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
However, we don't know of anyone who has tried to do this in a very
long time, and are therefore considering removing the remaining
support for the VAX platform. Has anyone tried to build PostgreSQL
for VAX lately?
Actually I tried a while ago but got stuck configuring the network on
simh so I could get all the tools. I can try again if there's interest
but we don't necessarily need to keep a port just because there's a
simulator for it.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 06/23/2014 06:58 PM, Greg Stark wrote:
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
However, we don't know of anyone who has tried to do this in a very
long time, and are therefore considering removing the remaining
support for the VAX platform. Has anyone tried to build PostgreSQL
for VAX lately?Actually I tried a while ago but got stuck configuring the network on
simh so I could get all the tools. I can try again if there's interest
but we don't necessarily need to keep a port just because there's a
simulator for it.
...not to mention actual hardware.
-Dave
--
Dave McGuire, AK4HZ/3
New Kensington, PA
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark <stark@mit.edu> wrote:
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
However, we don't know of anyone who has tried to do this in a very
long time, and are therefore considering removing the remaining
support for the VAX platform. Has anyone tried to build PostgreSQL
for VAX lately?Actually I tried a while ago but got stuck configuring the network on
simh so I could get all the tools. I can try again if there's interest
but we don't necessarily need to keep a port just because there's a
simulator for it.
That's really up to you. I'm not particularly interested in
generating interest in maintaining this port if there wouldn't
otherwise be any; I'm trying to figure out whether there is existing
interest in it. For all I know, <whatever>BSD is shipping PostgreSQL
binaries for VAX and every other platform they support in each new
release and people are using them to get real work done. Then again,
for all I know, it doesn't even compile on that platform, and if you
did manage to get it to compile it wouldn't fit on the disk, and if
you managed to fit it on the disk it wouldn't work because key system
calls aren't supported. If someone is still interested in this, I'm
hoping they'll help us figure out whether it's anywhere close to
working, and maybe even contribute a buildfarm critter. If no one
cares, then let's just rip it out and be done with it.
--
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
On Tuesday, June 24, 2014 03:12 CEST, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark <stark@mit.edu> wrote:
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
However, we don't know of anyone who has tried to do this in a very
long time, and are therefore considering removing the remaining
support for the VAX platform. Has anyone tried to build PostgreSQL
for VAX lately?Actually I tried a while ago but got stuck configuring the network on
simh so I could get all the tools. I can try again if there's interest
but we don't necessarily need to keep a port just because there's a
simulator for it.That's really up to you. I'm not particularly interested in
generating interest in maintaining this port if there wouldn't
otherwise be any; I'm trying to figure out whether there is existing
interest in it. For all I know, <whatever>BSD is shipping PostgreSQL
binaries for VAX and every other platform they support in each new
release and people are using them to get real work done. Then again,
for all I know, it doesn't even compile on that platform, and if you
did manage to get it to compile it wouldn't fit on the disk, and if
you managed to fit it on the disk it wouldn't work because key system
calls aren't supported. If someone is still interested in this, I'm
hoping they'll help us figure out whether it's anywhere close to
working, and maybe even contribute a buildfarm critter. If no one
cares, then let's just rip it out and be done with it.
I'm building the vax packages for openbsd. What I can tell is that
for 5.5 no postgresql packages were built. But that may be that
due to the recent upgrade from gcc 2.95 to 3.3.
I guess that not all dependencies to actually build postgresql
are available for the vax, or may build successfully there. But I need
to verify. Might need a few days, since I'm currently on vacation,
with sparse Internet connectivity. ;)
Sebastian
--
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
On Tuesday, June 24, 2014 13:37 CEST, "Sebastian Reitenbach" <sebastia@l00-bugdead-prods.de> wrote:
On Tuesday, June 24, 2014 03:12 CEST, Robert Haas <robertmhaas@gmail.com> wrote:
On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark <stark@mit.edu> wrote:
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <robertmhaas@gmail.com> wrote:
However, we don't know of anyone who has tried to do this in a very
long time, and are therefore considering removing the remaining
support for the VAX platform. Has anyone tried to build PostgreSQL
for VAX lately?Actually I tried a while ago but got stuck configuring the network on
simh so I could get all the tools. I can try again if there's interest
but we don't necessarily need to keep a port just because there's a
simulator for it.That's really up to you. I'm not particularly interested in
generating interest in maintaining this port if there wouldn't
otherwise be any; I'm trying to figure out whether there is existing
interest in it. For all I know, <whatever>BSD is shipping PostgreSQL
binaries for VAX and every other platform they support in each new
release and people are using them to get real work done. Then again,
for all I know, it doesn't even compile on that platform, and if you
did manage to get it to compile it wouldn't fit on the disk, and if
you managed to fit it on the disk it wouldn't work because key system
calls aren't supported. If someone is still interested in this, I'm
hoping they'll help us figure out whether it's anywhere close to
working, and maybe even contribute a buildfarm critter. If no one
cares, then let's just rip it out and be done with it.I'm building the vax packages for openbsd. What I can tell is that
for 5.5 no postgresql packages were built. But that may be that
due to the recent upgrade from gcc 2.95 to 3.3.
I guess that not all dependencies to actually build postgresql
are available for the vax, or may build successfully there. But I need
to verify. Might need a few days, since I'm currently on vacation,
with sparse Internet connectivity. ;)
OK, that was easy:
$ cd /usr/ports/databases/postgresql
$ make install
===> postgresql-client-9.3.4p0 requires shared libraries .
OpenBSD VAX is static only, so no postgresql on OpenBSD
VAX before shared libraries will ever be made working on it.
cheers,
Sebastian
Sebastian
--
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
On Tue, Jun 24, 2014 at 7:45 AM, Sebastian Reitenbach
<sebastia@l00-bugdead-prods.de> wrote:
I'm building the vax packages for openbsd. What I can tell is that
for 5.5 no postgresql packages were built. But that may be that
due to the recent upgrade from gcc 2.95 to 3.3.
I guess that not all dependencies to actually build postgresql
are available for the vax, or may build successfully there. But I need
to verify. Might need a few days, since I'm currently on vacation,
with sparse Internet connectivity. ;)OK, that was easy:
$ cd /usr/ports/databases/postgresql
$ make install
===> postgresql-client-9.3.4p0 requires shared libraries .OpenBSD VAX is static only, so no postgresql on OpenBSD
VAX before shared libraries will ever be made working on it.
Thanks very much; that's useful information.
--
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
Well the latest NetBSD/vax package build doesn't seem to include any
PostgreSQL packages
http://ftp.netbsd.org/pub/pkgsrc/packages/NetBSD/vax/6.0_2014Q1/ but I
don't know why.
I'll try a quick (hah :) build this end to see what happens
David
On 24 June 2014 02:12, Robert Haas <robertmhaas@gmail.com> wrote:
Show quoted text
On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark <stark@mit.edu> wrote:
On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas <robertmhaas@gmail.com>
wrote:
However, we don't know of anyone who has tried to do this in a very
long time, and are therefore considering removing the remaining
support for the VAX platform. Has anyone tried to build PostgreSQL
for VAX lately?Actually I tried a while ago but got stuck configuring the network on
simh so I could get all the tools. I can try again if there's interest
but we don't necessarily need to keep a port just because there's a
simulator for it.That's really up to you. I'm not particularly interested in
generating interest in maintaining this port if there wouldn't
otherwise be any; I'm trying to figure out whether there is existing
interest in it. For all I know, <whatever>BSD is shipping PostgreSQL
binaries for VAX and every other platform they support in each new
release and people are using them to get real work done. Then again,
for all I know, it doesn't even compile on that platform, and if you
did manage to get it to compile it wouldn't fit on the disk, and if
you managed to fit it on the disk it wouldn't work because key system
calls aren't supported. If someone is still interested in this, I'm
hoping they'll help us figure out whether it's anywhere close to
working, and maybe even contribute a buildfarm critter. If no one
cares, then let's just rip it out and be done with it.--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
"Sebastian Reitenbach" <sebastia@l00-bugdead-prods.de> writes:
OK, that was easy:
$ cd /usr/ports/databases/postgresql
$ make install
===> postgresql-client-9.3.4p0 requires shared libraries .
OpenBSD VAX is static only, so no postgresql on OpenBSD
VAX before shared libraries will ever be made working on it.
Ouch. We long ago passed the point of no return as far as requiring
shared library support: there's too much backend functionality that's
in separate shared libraries rather than being linked directly into
the core executable. I doubt anyone will be interested in taking on
the task of supporting a parallel all-static build.
I think this means we can write off VAX on NetBSD/OpenBSD as a viable
platform for Postgres :-(. I'm sad to hear it, but certainly have
not got the cycles personally to prevent it.
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 06/24/2014 12:42 PM, Tom Lane wrote:
"Sebastian Reitenbach" <sebastia@l00-bugdead-prods.de> writes:
OK, that was easy:
$ cd /usr/ports/databases/postgresql
$ make install
===> postgresql-client-9.3.4p0 requires shared libraries .OpenBSD VAX is static only, so no postgresql on OpenBSD
VAX before shared libraries will ever be made working on it.Ouch. We long ago passed the point of no return as far as requiring
shared library support: there's too much backend functionality that's
in separate shared libraries rather than being linked directly into
the core executable. I doubt anyone will be interested in taking on
the task of supporting a parallel all-static build.I think this means we can write off VAX on NetBSD/OpenBSD as a viable
platform for Postgres :-(. I'm sad to hear it, but certainly have
not got the cycles personally to prevent it.
Nonono...NetBSD/vax has had shared library support for many years.
It's only OpenBSD that has that limitation.
-Dave
--
Dave McGuire, AK4HZ/3
New Kensington, PA
--
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 skrev 2014-06-24 18:42:
"Sebastian Reitenbach" <sebastia@l00-bugdead-prods.de> writes:
OK, that was easy:
$ cd /usr/ports/databases/postgresql
$ make install
===> postgresql-client-9.3.4p0 requires shared libraries .
OpenBSD VAX is static only, so no postgresql on OpenBSD
VAX before shared libraries will ever be made working on it.Ouch. We long ago passed the point of no return as far as requiring
shared library support: there's too much backend functionality that's
in separate shared libraries rather than being linked directly into
the core executable. I doubt anyone will be interested in taking on
the task of supporting a parallel all-static build.I think this means we can write off VAX on NetBSD/OpenBSD as a viable
platform for Postgres :-(. I'm sad to hear it, but certainly have
not got the cycles personally to prevent it.
OpenBSD/vax is static only. NetBSD/vax has dynamic libraries.
-- Ragge
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jun 24, 2014, at 9:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
I think this means we can write off VAX on NetBSD/OpenBSD as a viable
platform for Postgres :-(. I'm sad to hear it, but certainly have
not got the cycles personally to prevent it.
Why? NetBSD/vax has supported shared libraries for a long long time.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Jun 24, 2014, at 12:42 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Sebastian Reitenbach" <sebastia@l00-bugdead-prods.de> writes:
OK, that was easy:
$ cd /usr/ports/databases/postgresql
$ make install
===> postgresql-client-9.3.4p0 requires shared libraries .OpenBSD VAX is static only, so no postgresql on OpenBSD
VAX before shared libraries will ever be made working on it.Ouch. We long ago passed the point of no return as far as requiring
shared library support: there's too much backend functionality that's
in separate shared libraries rather than being linked directly into
the core executable. I doubt anyone will be interested in taking on
the task of supporting a parallel all-static build.I think this means we can write off VAX on NetBSD/OpenBSD as a viable
platform for Postgres :-(. I'm sad to hear it, but certainly have
not got the cycles personally to prevent it.
NetBSD and OpenBSD are different systems. I don’t remember if NetBSD supports shared libraries on VAX, but that’s independent of the fact that OpenBSD doesn’t.
paul
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Dave McGuire <mcguire@neurotica.com> writes:
On 06/24/2014 12:42 PM, Tom Lane wrote:
I think this means we can write off VAX on NetBSD/OpenBSD as a viable
platform for Postgres :-(. I'm sad to hear it, but certainly have
not got the cycles personally to prevent it.
Nonono...NetBSD/vax has had shared library support for many years.
It's only OpenBSD that has that limitation.
Ah, thanks for the clarification.
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
Dave McGuire wrote:
On 06/24/2014 12:42 PM, Tom Lane wrote:
I think this means we can write off VAX on NetBSD/OpenBSD as a viable
platform for Postgres :-(. I'm sad to hear it, but certainly have
not got the cycles personally to prevent it.Nonono...NetBSD/vax has had shared library support for many years.
It's only OpenBSD that has that limitation.
So now we know that NetBSD/vax is free of the shared library limitation
that plagues OpenBSD, but does Postgres work on NetBSD/vax otherwise?
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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
Hi,
Has anyone tried to build PostgreSQL for VAX lately? If so, did it
compile? Did you have to use --disable-spinlocks to get it to compile?
If it did compile, can you actually run it, and does it pass the
regression tests and work as expected? Would you be willing to work
with the PostgreSQL to ensure continuing support for this platform, or
does that seem not worthwhile for whatever reason?
I've compiled postgresql93-client and postgresql93-server from pkgsrc on a
VAX running NetBSD 6.1.4. The initial launch didn't like the default stack
limit:
/etc/rc.d/pgsql start
Initializing PostgreSQL databases.
LOG: invalid value for parameter "max_stack_depth": 100
DETAIL: "max_stack_depth" must not exceed 0kB.
HINT: Increase the platform's stack depth limit via "ulimit -s" or local
equivalent.
FATAL: failed to initialize max_stack_depth to 100
child process exited with exit code 1
initdb: removing data directory "/usr/local/pgsql/data"
pg_ctl: database system initialization failed
I unlimited and tried again. The pgsql process showed it was using 146
megabytes of memory while initializing, then got as far as:
/etc/rc.d/pgsql start
Initializing PostgreSQL databases.
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
Starting pgsql.
Then the machine paniced. The serial console showed:
panic: usrptmap space leakage
cpu0: Begin traceback...
panic: usrptmap space leakage
Stack traceback :
Process is executing in user space.
cpu0: End traceback...
dump to dev 9,1 not possible
It does compile and initialize, so the VAX code does work. However,
considering how much memory it uses, I wonder how many people would
actually use it. I did run Apache / MySQL / PHP on a VAXstation 4000/60
not long ago, but MySQL takes way too much memory, too. Don't even get me
started on how memory PHP uses - someone has to write some good weblog
software in C one of these days...
John
--
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, Jun 24, 2014 at 10:16 PM, John Klos <john@ziaspace.com> wrote:
Has anyone tried to build PostgreSQL for VAX lately? If so, did it
compile? Did you have to use --disable-spinlocks to get it to compile? If
it did compile, can you actually run it, and does it pass the regression
tests and work as expected? Would you be willing to work with the
PostgreSQL to ensure continuing support for this platform, or does that seem
not worthwhile for whatever reason?I've compiled postgresql93-client and postgresql93-server from pkgsrc on a
VAX running NetBSD 6.1.4. The initial launch didn't like the default stack
limit:/etc/rc.d/pgsql start
Initializing PostgreSQL databases.
LOG: invalid value for parameter "max_stack_depth": 100
DETAIL: "max_stack_depth" must not exceed 0kB.
HINT: Increase the platform's stack depth limit via "ulimit -s" or local
equivalent.
FATAL: failed to initialize max_stack_depth to 100
child process exited with exit code 1
initdb: removing data directory "/usr/local/pgsql/data"
pg_ctl: database system initialization failedI unlimited and tried again. The pgsql process showed it was using 146
megabytes of memory while initializing, then got as far as:/etc/rc.d/pgsql start
Initializing PostgreSQL databases.
What value did it select for shared_buffers? How much memory does a
high-end VAX have? These days, we try to set shared_buffers = 128MB
if the platform will support it, but it's supposed to fall back to
smaller values if that doesn't work. It will try allocating that much
though, at least for a moment, to see whether it can.
--
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
John Klos skrev 2014-06-25 04:16:
Then the machine paniced. The serial console showed:
panic: usrptmap space leakage
cpu0: Begin traceback...
panic: usrptmap space leakage
Stack traceback :
Process is executing in user space.
cpu0: End traceback...
Hm, can you add info about this panic to PR #28379 ? I will try to hunt
this down soon, so I need some test cases.
-- Ragge
Hi,
What value did it select for shared_buffers? How much memory does a
high-end VAX have? These days, we try to set shared_buffers = 128MB
if the platform will support it, but it's supposed to fall back to
smaller values if that doesn't work. It will try allocating that much
though, at least for a moment, to see whether it can.
A high end VAX, such as a 4000 Model 108, can have 512 megs (as can an
11/780, at least in theory), but most of the VAXen used here are
VAXstations such as the 4000/60 or 4000/90, 90a or 96, which have either
104 megs or 128 megs.
I was trying it just using the default postgresql.conf. I changed it:
< max_connections = 10 # (change requires restart)
max_connections = 40 # (change requires restart)
< shared_buffers = 16MB # min 128kB
shared_buffers = 128MB # min 128kB
< temp_buffers = 2MB # min 800kB
< max_prepared_transactions = 0 # zero disables the feature
#temp_buffers = 8MB # min 800kB
#max_prepared_transactions = 0 # zero disables the feature
< maintenance_work_mem = 8MB # min 1MB
< max_stack_depth = 1MB # min 100kB
#maintenance_work_mem = 16MB # min 1MB
#max_stack_depth = 2MB # min 100kB
< max_files_per_process = 100 # min 25
#max_files_per_process = 1000 # min 25
and it launched fine. I then tried to run:
gmake MAX_CONNECTIONS=5 installcheck
in /usr/pkgsrc/databases/postgresql93-server/work/postgresql-9.3.4/src/test/regress,
but it failed with:
...
gmake[2]: Leaving directory
'/usr/pkgsrc/databases/postgresql93-server/work/postgresql-9.3.4/src/backend'
gcc -O1 -fgcse -fstrength-reduce -fgcse-after-reload -I/usr/include
-I/usr/local/include -Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute
-Wformat-security -fno-strict-aliasing -fwrapv -pthread -mt -D_REENTRANT
-D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -I../../src/port -DFRONTEND
-I../../src/include -I/usr/include -I/usr/local/include -c -o thread.o
thread.c
cc1: error: unrecognized
command line option "-mt" <builtin>: recipe for target 'thread.o' failed
gmake[1]: *** [thread.o] Error 1
gmake[1]: Leaving directory
'/usr/pkgsrc/databases/postgresql93-server/work/postgresql-9.3.4/src/port'
../../../src/Makefile.global:423: recipe for target 'submake-libpgport'
failed
gmake: *** [submake-libpgport] Error 2
That's all I have time for tonight. Is there an easier way to run a
testsuite?
Thanks,
John
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 24/06/14 10:16 PM, John Klos wrote:
Hi,
Has anyone tried to build PostgreSQL for VAX lately? If so, did it
compile? Did you have to use --disable-spinlocks to get it to
compile? If it did compile, can you actually run it, and does it pass
the regression tests and work as expected? Would you be willing to
work with the PostgreSQL to ensure continuing support for this
platform, or does that seem not worthwhile for whatever reason?I've compiled postgresql93-client and postgresql93-server from pkgsrc on
a VAX running NetBSD 6.1.4. ...
It does compile and initialize, so the VAX code does work. However,
considering how much memory it uses, I wonder how many people would
actually use it. I did run Apache / MySQL / PHP on a VAXstation 4000/60
I guess I shan't expect to run PgSQL on a MicroVAX II (9MB), NetBSD
1.4.1. I did get Apache 1.3.x built on it.
not long ago, but MySQL takes way too much memory, too. Don't even get
me started on how memory PHP uses - someone has to write some good
weblog software in C one of these days...
If only C and PHP weren't the only options!
--T
John
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
