Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
Well, the issue from our point of view is that a lot of what we care about testing is extremely low-level hardware behavior, like whether spinlocks work as expected across processors. It's not clear that a simulator would provide a sufficiently accurate emulation. OTOH, the really nasty issues like cache coherency rules don't arise in single-processor systems. So unless you have a multiprocessor VAX available to spin up, a simulator may tell us as much as we'd learn anyway. (If you have got one, maybe some cash could be found --- we do have project funds available, and I think they'd be well spent on testing purposes. I don't make those decisions though.) Depending on how often you'd like the system to try to run a compile, I'd be happy to run it on a VAXstation 4000/60. It runs bulk package builds for pkgsrc, but we could do a compile every week or so (every day would really eat into cycles for other packages). John -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
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 think it did create a working configuration (with the exception of postgresql.conf), because I can run psql and do stuff on the command line: psql --username=pgsql postgres psql (9.3.4) Type "help" for help. postgres=# CREATE DATABASE test; CREATE DATABASE postgres=# CREATE USER testuser WITH PASSWORD 'test'; CREATE ROLE postgres=# GRANT ALL PRIVILEGES ON DATABASE test to testuser; GRANT postgres=# CREATE SCHEMA testschema; CREATE SCHEMA postgres=# CREATE TABLE testschema.testtable (testserial serial PRIMARY KEY, testchar varchar (100) NOT NULL); CREATE TABLE I don't know enough to really test this. Can you recommend a simple script to do some PostgreSQL testing? John -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
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" : 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
Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
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
