Re: [HACKERS] PostgreSQL for VAX on NetBSD/OpenBSD
On 20 August 2015 at 14:54, Greg Stark st...@mit.edu wrote: On Wed, Jun 25, 2014 at 6:05 PM, John Klos j...@ziaspace.com wrote: 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. So I've been playing with this a bit. I have simh running on my home server as a Vax 3900 with NetBSD 6.1.5. My home server was mainly intended to be a SAN and its cpu is woefully underpowered so the resulting VAX is actually very very slow. So slow I wonder if there's a bug in the emulator but anyways. I've run NetBS/vax in simh on a laptop with a 2.5Ghz i5-2520M and it feels reasonably fast or a VAX (make of that what you will :) I'm coming to the conclusion that the port doesn't really work practically speaking but the failures are more interesting than I expected. They come in a few varieties: Mmm. edge cases and failing (probably reasonable :) assumptions. 1) Vax does not have IEEE fp. This manifests in a few ways, some of which may be our own bugs or missing expected outputs. The numeric data type maths often produce numbers rounded off differently, the floating point tests print numbers one digit shorter than our expected results expect and sometimes in scientific notation where we don't expect. The overflow tests generate floating point exceptions rather than overflows. Infinity and NaN don't work. The Json code in particular generates large numbers where +/- Infinity literals are supplied. There are some planner tests that fail with floating point exceptions -- that's probably a bug on our part. And I've seen at least one server crash (maybe two) apparently caused by one as well which I don't believe is expected. Sounds like some useful test cases there. 2) The initdb problem is actually not our fault. It looks like a NetBSD kernel bug when allocating large shared memory blocks on a machine without lots of memory. There's not much initdb can do with a kernel panic... That should definitely be fixed... BSD still has the problem of kern.maxfiles defaulting to a value low enough that even two connections causes the regression tests to run out of file descriptors. That's documented and it would be a right pain for initdb to detect that case. Is initdb calling ulimit() to check/set open files? Its probably worth it as a sanity check if nothing else. I think the VAX default open_max is 128. The 'bigger' ports have a default of 1024, and I think they should probably all be updated to that, though that is orthogonal to a ulimit() check. 3) The tests take so long to run that autovacuum kicks in and the tests start producing rows in inconsistent orderings. I assume that's a problem we've run into on the CLOBBER_CACHE animals as well? Can the autovaccum daemon settings be bumped/disabled while running the tests? 4) One of the tablesample tests seems to freeze indefinitely. I haven't looked into why yet. That might indeed indicate that the spinlock code isn't working? So my conclusion tentatively is that while the port doesn't actually work practically speaking it is nevertheless uncovering some interesting bugs. Good to hear. Looks like bugs in both the OS and software side, so fun for all. Thanks for taking the time to do this! David -- 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
On 25 June 2014 12:38, Toby Thain t...@telegraphics.com.au wrote: 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. I suspect it might technically be possible to run PgSQL on that hardware - probably best done with an app on another box (maybe a second uVAX II :) which is not in a particular hurry for query responses 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! Tsk, how could we forget VAX MACRO assembler :-p -- 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 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 robertmh...@gmail.com wrote: On Mon, Jun 23, 2014 at 6:58 PM, Greg Stark st...@mit.edu wrote: On Mon, Jun 23, 2014 at 3:09 PM, Robert Haas robertmh...@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, whateverBSD 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
