Postgres for OpenVMS

Hi Postgresql Developers!

A few weeks ago I posted a message on the pgsql-general list asking about a
possible port of Postgresql to OpenVMS.

Bruce Momjian (who has a lot of VMS experience) wrote me back explaining
the difficulties involved in such a port.

Well, since Bruce's note, I have been poking aroung in the VMS community
and lo and behold, one of my VMS colleagues (David Mathog at Caltech) had
actually begun to look at this in conjunction with my efforts.

I had an email exchange with David today and I have attached it below. I
hope the Postgresql team may have an opportunity to look it over and
(perhaps) consider revisiting the possibility of a "VMS port" of Postgresql
or at least maybe a "VMS team".

Here is a condensed synopsis of my emails with Dave.

Best Regards (and THANKS FOR A DYNAMITE DATABASE!!!),

Jim
.......................................................
I've been looking for an affordable database system for our OpenVMS system,
so far, with no luck. In that quest I've examined some of the freeware
database systems. I couldn't make heads or tails of MySql or Interbase
(especially their build procedures). But a recent slashdot thread on the
excellent performance of Postgresql convinced me to give it a try.

I only allowed myself one workday for this - if it didn't all fall
substantially into place by then I wasn't going to pursue it. And it didn't
get far enough for me to go on within that time limit but somebody else
may want to pick up the pieces (which will at least save them from having
to start totally from scratch). The distribution is here:

ftp://seqaxp.bio.caltech.edu/software/pgsql_vms_partial_port.zip

(It's big - 16872 blocks!) Look at aaa_vms_port_notes.txt in the top
directory, and then to do the partial build do

$ set def [.src]
$ set ver
$ @make_vms

The partial port is based on an edited log of a build on Linux/Intel. It is
pretty depressingly for those of us who hope that OpenVMS has a future to
watch a large package like this build without a hitch on Linux/Intel, and
to compile at roughly 100x the rate that is obtained on OpenVMS (due
entirely to the file IO wrapped up in the 100 or so #include operations
typical for each module - and the current lack of an effective file caching
system on OpenVMS.) Anyway, the Linux build supplied enough information to
put together most (not all) of an OpenVMS build procedure.

The good news is that most of the code seems to be pretty well written -
for Unix code. By that I mean that while it doesn't conform to any one
C language standard, the vast majority of it compiled with some combination
of defined language standards, and the rest could be built with
/standard=relaxed so long as they didn't also require some Unix API not
present on VMS. (Just don't expect /warn=(enable=all) to be silent, even
though it flies through gcc -Wall on linux quietly.) In short, something
like 95% of it could be compiled cleanly "out of the box", and most of the
rest of that 5% were routines that need to be replaced anyway. That's a
lot better than most packages I see. (See aaa_vms_port_notes.txt
for some of the potential bugs I saw - none of which were resolved.)

The bad news is that the entire IPC section needs to be rewritten to use
native VMS APIs - but that does also open up the opportunity to make it
more "cluster" aware. (Thanks to Dan O'Reilly for identifying the "UNIX
domain sockets" pieces, which I'd never seen before.) Those few of you
who know your way around the innards of multithreaded OpenVMS web servers
may be able to make quick work of the rest of the port - the issues left
unresolved by my work are those already resolved in such servers.

After looking at the Postgresql code it looks like a review their code
for missing ifdefs, especially HAVE_SYS_PARAM_H may help. Those sorts of
things are set up by "configure" but I found numerous instances where the
code did not apply the appropriate #ifdef and I had to put it in. I think
it also would be good have a look at my port notes as the VMS compiler
flagged a bunch of things that were either outright bugs or were done in a
nonportable manner.

For instance

if(foo == -1)

when foo (at least on OpenVMS) is an unsigned int.

The build procedure for this is the poster child for the speed limitations
currently built into VMS systems. It took forever to chunk through this
pile of code on my DS10, and something like a minute to do it on RH 5.2/
Intel on a 400 Mhz PII. (But if you do some line like

$ cc.... source.c

and

$ cc..../preproc source.c
$ cc.... source.i

you'll find that the compilation of the .i file is about 6 times faster than
that of the .c, ie, it's all file access time grinding through the includes.)


Anyway, good luck to whoever wants to have a shot at this next.

,-,-. ,-,-. ,-,-. ,-,-. ,-
/ / \ \ / / \ \ / / \ \ / / \ \ / /
\ \ / / \ \ / / \ \ / / \ \ / /
`-'-' `-'-' `-'-' `-'-'
--------------------------------------------------------
FSC - Building Better Information Technology Solutions-
From the Production Floor to the Customer's Door.
--------------------------------------------------------

Jim Jennis, Technical Director, Commercial Systems
Fuentez Systems Concepts, Inc.
1 Discovery Place, Suite 2
Martinsburg, WV. 25401 USA.

Phone: +001 (304) 263-0163 ext 235
FAX: +001 (304) 263-0702

Email: jjennis(at)fuentez(dot)com
jhjennis(at)shentel(dot)net
Web: http://www.discovery.fuentez.com/
---------------------------------------------------