.\" .\" POSTGRES Data Base Management System .\" .\" Copyright (c) 1988 Regents of the University of California .\" .\" Permission to use, copy, modify, and distribute this software and its .\" documentation for educational, research, and non-profit purposes and .\" without fee is hereby granted, provided that the above copyright .\" notice appear in all copies and that both that copyright notice and .\" this permission notice appear in supporting documentation, and that .\" the name of the University of California not be used in advertising .\" or publicity pertaining to distribution of the software without .\" specific, written prior permission. Permission to incorporate this .\" software into commercial products can be obtained from the Campus .\" Software Office, 295 Evans Hall, University of California, Berkeley, .\" Ca., 94720. The University of California makes no representations .\" about the suitability of this software for any purpose. It is .\" provided "as is" without express or implied warranty. .\" .\" ---------------------------------------------------------------- .\" POSTGRES version 4.1 setup instructions .\" .\" ---------------------------------------------------------------- .de RV .ie "\\$2"" \ \{\ . ds VT " . ds VN " . ds VD \*(td .\} .el \ \{\ . ds VT \\$7 . ds VD \\$4 . ds VN \\$3 .\} .. .hx .fo ''%'' .ce 99 .ps 18 .b POSTGRES INSTALLATION INSTRUCTIONS .r .ps 14 .sp 0.25v Release 4.1 .sp 0.25v .ce 0 .sp .\" ---------------- .\" Document Overview .\" ---------------- .ds PG "\\s-2POSTGRES\\s+2 .sh 0 "Document Overview" .(l Introduction Site Requirements Hardware Software Distribution Tape Expertise Configuration Operating System Disk Requirements Kernel Installing \*(PG Preparation Finding a Good Place for \*(PG Creating the \*(PG Directory Creating the \*(PG User Loading \*(PG From Tape Loading \*(PG From a Tar File Configuration Kernel Reconfiguration for Sparcs Kernel Reconfiguration for DEC's Running the Pre-installed \*(PG System Compiling and Installing \*(PG Creating the Initial Database Testing Running \*(PG The \*(PG Postmaster The \*(PG Terminal Monitor The \*(PG Backend \*(PG Support Programs Optional Installation Installing LIBPQ, the \*(PG Frontend Library \*(PG Header Files Wisconsin Benchmark Database Minimal Installation Documentation Miscellaneous Bug Reports Consulting \*(PG BBS .)l .bp .\" ---------------- .\" Introduction .\" ---------------- .sh 1 "Introduction" .lp This document gives installation instructions for the \*(PG database system under development at the University of California, Berkeley. \*(PG is distributed in source code format and is the property of the Regents of the University of California. However, the University will grant unlimited commercialization rights for any derived work on the condition that an educational license to the derived work is obtained. For further information, consult the Berkeley Campus Software Office, 295 Evans Hall, University of California, Berkeley, CA 94720. .lp The University and the \*(PG development group provide no warranty as to the fitness of the code for any purpose whatsoever, and cannot guarantee to assist in fixing problems. This is \fIunsupported\fP software. .\" ---------------- .\" Site Requirements .\" ---------------- .sh 1 "Site Requirements" .lp .sh 2 "Hardware" .lp \*(PG currently has been tested by the \*(PG development team on Sun Microsystems Sparc architecture machines running SunOS 4.1 and higher. \*(PG is also supported on DECstations 3100's and 5000's running Ultrix 4.1 and higher. In order to use \*(PG, your machine should have at least 8 megabytes of memory and you will require at least 45 megabytes of disk space to hold source, binaries, and user databases. If you choose to compile \*(PG for source-level debugging, you will need roughly twice as much disk space. See the section on compilation for details. .lp The Ultrix version requires a kernel which allows 4 megabytes of shared memory. Also, the original release of Ultrix 4.3 has a kernel bug that causes the operating system to hang when running \*(PG. The bug is in the shared memory module in the kernel, and a patch is available from DEC which fixes the bug. Contact your DEC representative for the patch. .sh 2 "Software" .sh 2 "Distribution Tape" .lp These instructions assume you have a \*(PG Version 4.1 distribution tape (in either 9 track, SCSI cartridge, or TK50 cartridge format) or a \*(PG tar file. This release comes with a pre-installed version of \*(PG ready to run for the two platforms we officially support. This is a test to see if our users can run the pre-installed system to avoid compiling the sources from scratch. Should any problems arise with the pre-installed system, it is recommended that the sources be rebuilt from scratch to rule out any compatability problems between the system we compiled on here and your own. There are two potential releases you may want (same source, different binaries). The tar version of the ultrix release is \f(CWpostgres-v4r1.ultrix.tar.Z\fP and the sparc release is \f(CWpostgres-v4r1.sparc.tar.Z\fP available via anonymous ftp from postgres.cs.berkeley.edu. .sh 2 "Expertise" .lp Once a site is properly configured and \*(PG is installed, very little UNIX expertise is required to maintain things. However, initially setting things up for your site to run \*(PG may be difficult and we advise that the person installing \*(PG be familiar with system administration procedures. Also note that various steps require superuser privilege on the system, so we advise that your site's system administrator read this document also. .sh 2 "Configuration" .lp This section briefly describes the configuration you need to run \*(PG. Read this to familiarize yourself with the procedure. Detailed instructions for making appropriate modifications to your system are given later in this document. .sh 3 "Operating System" .lp \*(PG expects things to be configured for BSD by default. If the default on your site is to use the SunOS SysV compiler and libraries then you may have to make some changes to this procedure before compiling \*(PG. .lp To compile this release from sources requires a new version of make which comes from the latest BSD release. A bootstrapping version of the make sources is included with this release, as is a precompiled binary with its configuration files. The make program is installed using the name \f(CWbmake\fP to avoid any conflict with your native make. .sh 3 "Disk Requirements" .lp \*(PG requires 50 megabytes of disk space, preferably on a single partition, to compile and install from sources. If you run the pre-installed system, you only need 25 megabytes to hold the executables and sources. .sh 3 "Kernel" .lp \*(PG makes use of the optional System V shared memory operations provided by SunOS and DEC Ultrix which require a properly configured kernel which is in general different than the factory-shipped generic kernel. See the section on kernel configuration for details. .\" ---------------- .\" Installation .\" ---------------- .sh 1 "Installing \*(PG" .lp There are potentially two routes you can go to install this system. Either you can choose to run the pre-installed system shipped with the release, or you can compile and install the sources from scratch. In either case your kernel must be configured to support the shared memory and semaphore operations required by the code. Assuming you have run \*(PG in the past, you may already be properly configured to run. Also, should you opt to run the pre-installed system, let us reiterate that if you run into any complications, it would be wise to recompile the sources from scratch before reporting any problems to our mailing list. We are, however, interested in any feedback you may have on the pre-installed system. In both cases you need to decide where to load the system. .\" ---------------- .\" Preparation .\" ---------------- .sh 2 "Step 1 \- Preparation" .lp Some of the tasks involved in this step normally fall in the domain of the site's system administrator and may require superuser privilege. If possible, we advise you to have your system administrator perform these steps. .sh 3 "Find a good place for \*(PG" .lp You should locate a disk partition with at least 50 megabytes of free space available for \*(PG. If you plan to run the pre-installed system, it would be best if you loaded the release into the directory \f(CW/usr/local/postgres\fP, as that is what the release was configured for. It is not mandatory, though, as the only relevent dependency is that the programs are setup to look for the database directory in \f(CW/usr/local/postgres/data\fP, but that can be changed by setting the environment variable PGDATA somwhere else before starting the postmaster. Also note that you can install the system anywhere, and then make a symbolic link from \f(CW/usr/local/postgres\fP to the place you really loaded the system. If you are compiling the system from scratch, it doesn't matter where you load the system at all (as long as there is space). .sh 3 "Creating the \*(PG directory" .lp Once you have decided, create the directory to hold the release if it doesn't already exist. Then \fBcd\fR to this directory and type \fBpwd\fR. This is the full path of the directory you will install \*(PG in. For example: .sp .(l # \fBdf\fR Filesystem kbytes used avail capacity Mounted on /dev/xy0a 8421 6703 875 88% / /dev/xy0f 10829 6743 3003 69% /pub.MC68020 /dev/xy2h 110811 81181 18548 81% /usr3 /dev/xy2g 221279 167405 31746 84% /b /dev/xy1g 221279 138365 60786 69% /usr/local /dev/xy1a 8179 944 6417 13% /tmp /dev/xy0h 119999 101623 6376 94% /usr.MC68020 /dev/xy0g 156033 135499 4930 96% /usr2 /dev/rf0d 539421 465026 20452 96% /a .i /usr/local looks like a good place (it has 60 megs free) so we decide to create the \*(PG directory there... .r # \fBcd /usr/local\fR # \fBmkdir postgres\fR # \fBcd postgres\fR # \fBpwd\fR /usr/local/postgres # .)l .sh 2 "Creating the \*(PG user" .lp Finally, we need to create a user called \*(PG whose shell is \f(CW/bin/csh\fP. Though not necessary, it is convenient to make the home directory of the \*(PG user the pathname where we install the system. This can be done using the "adduser" procedures particular to your platform and site. See your system administration manual for details. .lp The reason we make a postgres login is so that when we install the system and create the database directory, everything is owned by this postgres user. Then, we start the postmaster when logged in as this postgres user, and all the backends are also started by the user postgres and are able to access the databases. Although you can probably make this work without creating a postgres login (note that the restriction about having a postgres login with uid 6 was removed a while ago), we provide no support for doing so (you are, as they say, "on your own"). .\" ---------------- .\" Loading .\" ---------------- .sh 2 "Step 2 - Loading \*(PG" .lp Now you are ready to load the \*(PG files onto your system. To do this, you will need either a distribution tape or a \*(PG tar file (available via anonymous ftp from postgres.cs.berkeley.edu). .lp If you are loading \*(PG from a tape, follow these instructions; if you are loading from a tar file obtained via FTP, skip to the section "Loading \*(PG from a Tar File". .sh 3 "Loading \*(PG from a Tape" .lp Login as postgres and change directories to the postgres directory that was created. .lp 3. Run "tar" with the following options .lp % tar xvf .sp where is the name for your tape device, i.e., /dev/rmt0, /dev/rst8, etc. .lp The file "postgres-v4r1.XXX.tar.Z" will appear in your \*(PG home directory, where XXX is the name of the platform. You may need to re-wind your tape to get it out of your tape drive - see your system administrator for instructions. .lp Proceed to the next section "Loading \*(PG from a Tar File". .lp .sh 2 "Loading \*(PG from a Tar File" .lp If you are not logged in as \f(CWpostgres\fP already, do so now. For the purpose of this discussion, the \*(PG tar file will be called \f(CWpostgres-v4r1.XXX.tar.Z\fP .lp Uncompress the tar file. .(l % uncompress postgres-v4r1.XXX.tar.Z .)l .lp A larger file should now be in the \*(PG home directory, and the '.Z' ending should be gone, so it is now named postgres-v4r1.XXX.tar .lp Extract \*(PG from the tar file using the following command: .(l % tar xvf postgres-v4r1.XXX.tar .)l .lp Lots of file names and such should appear on the screen. This step may take several minutes. .lp Now do an "ls": .(l % ls .)l .lp The output of the ls should look something like: .(l .ft CW COPYRIGHT README doc local src INITIAL_SETUP bin include man Makefile data lib obj .ft .)l .lp At this point you have loaded the \*(PG files. Remove the tar file to get back the space. .(l % rm postgres-v4r1.XXX.tar .)l .sp .\" ---------------- .\" Configuration .\" ---------------- .sh 2 "Step 3 - Configuration" .lp This step requires familiarity with configuring a UNIX kernel. If you are unfamiliar with this procedure, we advise you to read the section on configuring a kernel in the SunOS or DEC system administration manual carefully. This task requires superuser privilege and should probably not be done without the assistance of your system administrator. We assume that whoever undergoes this procedure has an understanding of the process and procedures involved. .lp \*(PG uses shared memory segments which must be compiled into the kernel of the host which will act as the \*(PG server. If you try to run a \*(PG backend process on a machine without enough shared memory, the backend will abort with an error message. .lp This is by far the most complicated part of the installation so these steps should be performed by someone with system administration experience. Again, we advise you to consult the system administration section of your manual before doing this step. .lp For a brief discussion of shared memory, you may want to consult the Man pages for \fIshmget()\fR, \fIshmop()\fR, \fIshmctl()\fR, etc. Now proceed to the appropriate section for your machine. .lp .sh 3 "Kernel reconfiguration for Sparcs" .lp In order to reconfigure Sun or Sparc kernel, you will have to become root and add some lines to /usr/sys/conf (your kernel config file) and /usr/sys/conf/param.c (your kernel parameters file). We .i strongly advise you to make a spare copy of your system's original config and parameter files before you make any changes. .lp The following lines should be added to /usr/sys/conf/KERNEL: .sp .(l options IPCMESSAGE # SystemV IPC Message Facility options IPCSEMAPHORE # SystemV IPC Semaphore Facility options IPCSHMEM # SystemV IPC Shared-Memory Facility options EMOREIPCS # more semaphores and shared memory (for 8M) .)l .sp .lp At Berkeley, we substitute the line: .(l options EMOREIPCS # more semaphores and shared memory (for 8M) .)l .lp with the line: .(l options TTMOREIPCS # more semaphores and shared memory (for 32M) .)l .lp to allocate more shared memory so that we can run more \*(PG backends at the same time. Either of the lines will result in a kernel that has enough shared memory allocated. .lp Also add the following lines to the \fItop\fR of /usr/sys/conf/param.c: .sp .(l /* * LOCAL DEFINITIONS START */ #ifdef EMORESEMS #define EMOREIPCS #endif /* defined(EMORESEMS) */ #ifdef TTMORESEMS #define TTMOREIPCS #endif /* defined(TTMORESEMS) */ #ifdef EMOREIPCS #define SEMMNI 30 /* # of semaphore identifiers */ #define SEMMNS 180 /* # of semaphores in system */ #define SEMUME 10 /* max # of undo entries per process */ #define SEMMNU 30 /* # of undo structures in system */ #define SHMPOOL 1536 /* max total shared memory system wide (in Kbytes) */ #define SHMSEG 6 /* max attached shared memory segments per process */ #define SHMMNI 100 /* # of shared memory identifiers */ #endif /* defined(EMOREIPCS) */ #ifdef TTMOREIPCS #define SEMMNI 60 /* # of semaphore identifiers */ #define SEMMNS 384 /* # of semaphores in system */ #define SEMUME 10 /* max # of undo entries per process */ #define SEMMNU 30 /* # of undo structures in system */ #define SHMPOOL 8192 /* max total shared memory system wide (in Kbytes) */ #define SHMSEG 6 /* max attached shared memory segments per process */ #define SHMMNI 100 /* # of shared memory identifiers */ #endif /* defined(TTMOREIPCS) */ /* * LOCAL DEFINITIONS END */ .)l .lp After adding these lines, run config over the config file, install the new kernel, and reboot. .sp .sh 3 "Kernel reconfiguration for DECs" .lp In order to reconfigure your DECstation 3100 or 5000 Ultrix kernel, you will have to become root and add some lines to /usr/sys/conf (your kernel config file). .sp The following lines should be added to /usr/sys/conf/KERNEL: .sp .(l smmax 256 smseg 12 smbrk 1024 .)l .lp After adding these lines, run .i config over the configuration file, install the new kernel, and reboot. .lp Also, remember that Ultrix 4.2 has a kernel bug that causes the operating system to hang when running \*(PG. You should apply the DEC supplied patch at this point if you have not already. .sp .\" ---------------- .\" Running the pre-installed system .\" ---------------- .sh 2 "Running the pre-installed \*(PG system" .lp Assuming you have loaded the system into /usr/local/postgres, there is very little else to do. Add /usr/local/postgres/bin to your shell path. If you run csh, you would put .(l set path=(/usr/local/postgres/bin $path) .)l in the .login for the postgres user. Or if you run sh or ksh, put .(l PATH=/usr/local/postgres/bin:$PATH export PATH .)l in your .profile. Then log back in so the change takes effect. Now run the following command .(l % newbki .)l This will reset the userid of the special \*(PG user of the database to have the proper value. Even though newbki allows you to enter a login name, you should select the default value of \f(CWpostgres\fP. It allows a different name because at some point we plan to remove the restriction that a special user called \f(CWpostgres\fP even exists -- but not yet... .lp After doing this, you may wish to install the precompiled version of bmake into /usr/local/bin. This will allow you to recompile \*(PG right away without bootstrapping bmake. To do this, cd into the directory called "local". You will see two directories and a README. Become the superuser and do the following: .(l # cp bin/bmake /usr/local/bin # mkdir /usr/local/lib /usr/local/lib/mk (you may get an error if this directory alreadt exists - ignore it) # cp lib/mk/* /usr/local/lib/mk .)l .lp If you installed \*(PG somewhere other than /usr/local/postgres, everything can still work right if you set the environment variable PGDATA for the special \*(PG user. Lets assume you installed \*(PG in the directory "/private/packages/postgres". If you run csh, put the following in the .login for the \*(PG user .(l setenv PGDATA /private/packages/postgres/data .)l or if you run sh or ksh, put the following in .profile .(l PGDATA=/private/packages/postgres/data export PGDATA .)l This will instruct the postmaster and backends to look in that directory for the databases. .lp You can now skip to the setion called "Creating the initial database". .sp .\" ---------------- .\" Compiling and installing postgres .\" ---------------- .sh 2 "Compiling and Installing \*(PG" .lp The sources for \*(PG are all under the directory src/. The first step is to install the new bmake program. By the way, you can look at the previous section entitled "Running the pre-installed system" in the paragraph about bmake, and just copy the pre-compiled bmake to /usr/local/{bin,lib} if you want and skip step 2) in this section. What follows is a step by step list to compile and install this release from sources: .lp - build step 1: customization - .lp Cd into the src/ directory and edit the file "Makefile.global". By default the PORTNAME is "ultrix4". Change this to "sparc" if you are running on the sparcstation. Also, if you do not want "bmake" installed into /usr/local/bin and /usr/local/lib, change the values of TOOLSBINDIR and TOOLSLIBDIR and make sure these directories exist. .lp At this point you can also change where the \*(PG executable files are installed and where it looks for the database directory. In general the rest of the configuration switches are self-explanatory. The only one which must be set is PORTNAME. .lp - build step 2: bootstrapping the new bmake program - .lp Cd into src/tools/bmake and type .(l % make -f Makefile.boot .)l You may get warning messages during this bootstapping process about "illegal combination of pointer and integer" -- just ignore them. This should compile and install the "bmake" program and its supporting files, including the \*(PG related makefile templates. If all went well you will now be able to use the new make program by typing "bmake", assuming you have /usr/local/bin in your shell path. You may have to type "rehash" if you run csh(1), since it's too stupid to know new executables have been placed in its path. .lp - build step 3: compile and install the world - .lp Cd back to the src/ directory (i.e. cd ../..) and type .(l % bmake all install .)l This builds and installs the entire system. The Makefiles contain directives for running all the underlying Makefiles in all the directories, so the whole thing should unfold and compile beautifully and install to the target directory. Should this not be the case, it would be a good idea to save the results of the compile in a file. If you run csh(1), you could type .(l % bmake all install >& mk.log .)l and if you run ksh(1) or sh(1), type .(l % bmake all install > mk.log 2>&1 .)l This will save the results in the file "mk.log" so you can inspect it later. This would be an ideal opportunity to get some donuts and coffee. .sp .sh 2 "Creating the initial database" .lp \*(PG databases are stored in the directory .../postgres/data. After you have compiled \*(PG, you will need to create the initial database. If you haven't already put the path to the \*(PG executable programs in the shell path, do the following (assuming \*(PG was loaded into /usr/local/postgres). If you run csh, you would put .(l set path=(/usr/local/postgres/bin $path) .)l in the .login for the \*(PG user. Or if you run sh or ksh, put .(l PATH=/usr/local/postgres/bin:$PATH export PATH .)l in your .profile. Then log back in so the change takes effect. .lp Now you can create the initial database by running the following command. .(l % initdb .)l If that completes successfully, congratulations. .lp Now, to make the system operational you must run the postmaster. The section after "Testing" discusses this. .\" ---------------- .\" Testing .\" ---------------- .sh 2 "Step 4 - Testing" .lp We suggest you run the regression tests to make sure the release was installed successfully. You must have installed the bmake program to run the test. Also, you need to have the postmaste running to run the test, so type the following: .(l % postmaster & .)l .lp Change directories to src/regress/regress and type the following bmake command: .(l % cd src/regress/regress % bmake runtest .)l .lp This will run a whole slew of regression tests and might take a long time to run. When it's done, the output of the test is in the file "obj/regress.out". You can compare this to a sample run that we supply in the file "sample.regress.out" with the following command: .(l % diff sample.regress.out obj/regress.out .)l Unfortunatly you will see many differences corresponding to the timestamp lines and occasional lines where object id numbers (OID's) are different. We regret that we do not have a more sophisticated script for weeding out these innocuous differences at this time. If you see any differences not corresponding to time stamps or OIDS, there may be a problem. Have your local \*(PG expert take a look at it. .sp .\" ---------------- .\" Running .\" ---------------- .sh 1 "Running \*(PG" .lp \*(PG is designed to be a multiuser system. In practice, \*(PG consists of three (or more) processes: .ip \0\0\0\(bu the postmaster, .ip \0\0\0\(bu the terminal monitor, and .ip \0\0\0\(bu the backend. .lp Users are expected to use the terminal monitor for direct access to the database. The terminal monitor sends commands to the postmaster which forwards commands to a backend. .sh 2 "The \*(PG Postmaster" .lp The postmaster is a process which manages communication between the user's terminal monitor and a \*(PG backend. Without a running postmaster, the terminal monitor will not be able to connect to a backend. In general, the postmaster must be running for you (or others) to run any of the normal \*(PG commands. Always start the postmaster when logged in as the special "postgres" user, otherwise the system will not be able to access the database files. To start it, type .(l % postmaster & .)l Now you can leave the postmaster running if you wish to keep the database system accessable. In general, when the postmaster is running, the system is running. When it is not running, none of the frontend programs will work. .sp .sh 2 "The \*(PG Terminal Monitor" .lp The \*(PG terminal monitor is a front-end user interface to the \*(PG backend. .lp Lets assume \fIdatabase\fR is the name of the database you want to use. It is an error if \fIdatabase\fR does not exist, so to create the database, you would type .(l createdb \fIdatabase\fR .)l Now we will run the monitor: .(l % monitor \fIdatabase\fR .)l .(l .ft CW Welcome to the C POSTGRES terminal monitor Go * .ft \fI The ``*'' is the terminal monitor prompt. We are now talking to the backend, so let's send a simple test query: list the names and user ids of the \*(PG users. We terminate the query with a \eg \*- the ``go'' command to the terminal monitor. \fR *\fBretrieve (u.usename, u.usesysid) from u in pg_user \eg\fP .ft CW Query sent to backend is "retrieve (u.usename, u.usesysid) from u in pg_user" ----------------------------- | usename | usesysid | ----------------------------- | postgres | 6 | ----------------------------- | mike | 799 | ----------------------------- | sp | 1511 | ----------------------------- | jhingran | 943 | ----------------------------- | cimarron | 2359 | ----------------------------- | goh | 1994 | ----------------------------- | ong | 2802 | ----------------------------- | hong | 2469 | ----------------------------- | mao | 1806 | ----------------------------- | marc | 2435 | ----------------------------- | margo | 2697 | ----------------------------- | sullivan | 1517 | ----------------------------- | kemnitz | 3491 | ----------------------------- | choi | 3898 | ----------------------------- | mer | 3665 | ----------------------------- Go .ft .ft I .lp Okay, this worked, too. Now we'll quit. .lp *\fB\eq\fP .ft CW I live to serve you. .ft % .)l .sh 2 "The \*(PG Backend" .lp The \*(PG backend is the process which does all the \*(lqreal\*(rq work. This process is started by the postmaster when the postmaster receives a connection from a terminal monitor, so you should not normally need to start up the backend yourself. Should you wish to start the backend and talk to it directly (without a terminal monitor) you can do this by typing: .(l % \fBpostgres\fR \fIdatabase\fR .)l .lp where \fIdatabase\fR is the name of the database you wish to use. If you run a backend in this manner, you will be talking to the backend parser directly. We recommend using the terminal monitor; if you are using Postgres as a multiuser system, running the backend can result in locking failures and corrupt databases, as the Postmaster handles shared resources such as semaphores and shared memory. In general, never do this if there is a postmaster running. In addition, returned tuples are displayed more usefully and input is buffered better. The backend is used interactively primarily during debugging. .sh 2 "\*(PG Support Programs" .lp Included in \*(PG are a handful of support programs. Most of these are used internally by the system but here is a list of them for your information. .(l initdb \- creates the initial template database cleardbdir \- totally destroys the data/ directory, allowing a new initdb createdb \- creates new \*(PG databases createuser \- add a new user to the \*(PG system destroydb \- destroys \*(PG databases destroyuser \- delete a user from the datasbe system ipcclean \- frees up garbage shared memory from failed backends newbki \- adjust userid of "postgres" in the database pg_version \- make version numbers for createdb pg_id \- gets user id's - used by various commands pagedoc \- disk page doctor shmemdoc \- shared memory buffer pool doctor vacuum \- database vacuum cleaner pg_copytree \- copy te source tree (probably shouldn't be shipped) pcat \- inversion filesystem cat command pcd \- inversion filesystem cd command pls \- inversion filesystem ls command pmkdir \- inversion filesystem mkdir command pmv \- inversion filesystem mv command ppwd \- inversion filesystem pwd command prm \- inversion filesystem rm command prmdir \- inversion filesystem rmdir command .)l .sh 1 "Optional Installation" .sh 2 "Installing LIBPQ, the \*(PG frontend library" .lp The file .../lib/libpq.a is created when you install the system (or on the pre-installed system). This library contains various routines intended for use by frontend programs. You use this library if you want to execute \*(PG queries from a C program. If you plan on doing software development, you may wish to copy this file to /usr/lib so that the C compiler can reference it with -lpq. .sh 2 "Postgres header files" .lp The directory .../include contains copies of all the header files that front-end applications might need. You can compile a frontend program with the -I cc directive as illustrated in the following example: .(l cc -I/usr/local/postgres/include -o foo foo.c -lpq .)l .lp This feature of copying just the necessary header files into .../include was incorporated right before we produced the release and has not had sufficient testing. It your frontend programs complain about not being able to find header files, either add the missing header files to the include/ directory and notify us of the problem, or just point the -I compiler directive directly into the source as was done in the past. E.g. .(l cc -I/usr/local/postgres/src/backend -o foo foo.c -lpq .)l If you do this, you may need to add the following #define's in your source to set the PORTNAME - add them prior to any #includes: .(l #define PORTNAME ultrix4 #define PORTNAME_ultrix4 .)l for ultrix, or .(l #define PORTNAME sparc #define PORTNAME_sparc .)l We're sorry for any inconvenience this may cause, and fully intend that the include/ directory be more rigorously tested in the next release. .sh 2 "Wisconsin Benchmark Database" .lp In .../postgres/src/regress/bench are files which are the queries used in the Postgres version of the Wisconsin benchmark. The Wisconsin benchmark illustrates "basic" relational performance using B-Tree indices on nontrivial amounts of data. To run the benchmark, type cd to that directory and type .(l bmake runtest .)l .lp .sh 2 "Minimal Installation" .lp It is the intention that everything below the src/ directory can be removed, however we didn't have time to test this. Specifically, the include/ directory may not have all the necessary files to compile all the frontend programs, so you may might get burned if you remove the source. But if you'd like to try it out, we'd love to know if it works for you.... :) .\" ---------------- .\" Documentation .\" ---------------- .sh 1 "Documentation" Clear text and postscript versions of the manpages and documents are available in the directories man/ and doc/ at the top level. To recreate these documents, there are corresponding directories in src/{man,doc}. They are currently configured to require groff and friends, but you may be able to change the makefiles to use other facilities if you have them (good luck!). If you change directories to man/ and doc/ and type a .(l % bmake % bmake install .)l in each, it will format and install the documents into the corresponding destination directories. .\" ---------------- .\" Miscellaneous .\" ---------------- .sh 1 "Miscellaneous" .sh 2 "Bug reports" .lp If you find a bug with \*(PG, please send mail to .(l \0\0\0\0\0bug-postgres@postgres.Berkeley.EDU or \0\0\0\0\0(ucbvax!postgres!bug-postgres) .)l describing as precisely as possible the command that caused the problem, instructions on how to repeat the bug, and a script showing the bug. .sh 2 "Consulting" .lp This software is unsupported, public domain software. Although we are interested in feedback, it is impossible for us to make any commitment to support in a research environment. .lp If you do want to talk directly to the Postgres group, electronic mail is strongly preferred. We can be reached via the Internet as .(l \0\0\0\0\0post_questions@postgres.Berkeley.EDU or \0\0\0\0\0(ucbvax!postgres!post_questions) .)l We can also be reached at (510) 642-7520, Monday through Friday, between 1 and 4 PM Pacific Time. .lp .sh 2 "Postgres BBS" A mailing list for Postgres announcements and discussion is available for anyone who is interested. If you wish to subscribe to this mailing list, send mail to .(l \0\0\0\0\0postgres-request@postgres.Berkeley.EDU .)l with "Add" as the subject. Note that mail sent to this address is processed .b electronically. .lp The mailing list itself is called .(l \0\0\0\0\0postgres@postgres.Berkeley.EDU .)l and all mail sent to this address will be will be routed to the mailing list membership.