head 1.39; access; symbols; locks; strict; comment @.\" @; 1.39 date 94.06.30.09.10.17; author aoki; state Exp; branches; next 1.38; 1.38 date 94.06.02.00.12.07; author aoki; state Exp; branches; next 1.37; 1.37 date 94.04.02.07.55.27; author aoki; state Exp; branches; next 1.36; 1.36 date 94.04.01.21.46.43; author aoki; state Exp; branches; next 1.35; 1.35 date 94.03.27.06.11.28; author aoki; state Exp; branches; next 1.34; 1.34 date 94.03.14.12.52.43; author aoki; state Exp; branches; next 1.33; 1.33 date 94.03.11.01.26.53; author marc; state Exp; branches; next 1.32; 1.32 date 93.09.22.18.27.59; author aoki; state Exp; branches; next 1.31; 1.31 date 93.06.30.23.15.10; author aoki; state Exp; branches; next 1.30; 1.30 date 93.03.31.22.38.01; author marc; state Exp; branches; next 1.29; 1.29 date 93.02.26.00.06.39; author marc; state Exp; branches; next 1.28; 1.28 date 93.02.26.00.02.50; author marc; state Exp; branches; next 1.27; 1.27 date 93.02.25.23.15.38; author marc; state Exp; branches; next 1.26; 1.26 date 93.02.25.02.18.28; author marc; state Exp; branches; next 1.25; 1.25 date 92.08.27.06.08.25; author mer; state Exp; branches; next 1.24; 1.24 date 92.07.20.18.33.04; author frew; state Exp; branches; next 1.23; 1.23 date 91.12.02.10.16.38; author postgres; state Exp; branches; next 1.22; 1.22 date 91.12.02.04.15.58; author kemnitz; state Exp; branches; next 1.21; 1.21 date 91.08.18.07.51.47; author kemnitz; state Exp; branches; next 1.20; 1.20 date 91.08.18.05.41.18; author kemnitz; state Exp; branches; next 1.19; 1.19 date 91.08.18.05.12.25; author kemnitz; state Exp; branches; next 1.18; 1.18 date 91.08.18.03.39.50; author kemnitz; state Exp; branches; next 1.17; 1.17 date 91.08.18.02.38.57; author kemnitz; state Exp; branches; next 1.16; 1.16 date 91.08.18.02.31.52; author kemnitz; state Exp; branches; next 1.15; 1.15 date 91.08.16.04.21.21; author kemnitz; state Exp; branches; next 1.14; 1.14 date 91.03.09.05.00.09; author kemnitz; state Exp; branches; next 1.13; 1.13 date 91.03.07.03.45.05; author kemnitz; state Exp; branches; next 1.12; 1.12 date 91.01.15.18.00.07; author kemnitz; state Exp; branches; next 1.11; 1.11 date 90.11.01.17.00.14; author kemnitz; state Exp; branches; next 1.10; 1.10 date 90.10.28.13.57.01; author kemnitz; state Exp; branches; next 1.9; 1.9 date 90.10.28.13.54.37; author kemnitz; state Exp; branches; next 1.8; 1.8 date 90.10.27.20.10.59; author kemnitz; state Exp; branches; next 1.7; 1.7 date 90.10.27.19.57.35; author kemnitz; state Exp; branches; next 1.6; 1.6 date 90.10.27.19.52.29; author kemnitz; state Exp; branches; next 1.5; 1.5 date 90.10.27.19.48.23; author kemnitz; state Exp; branches; next 1.4; 1.4 date 90.10.27.18.52.01; author kemnitz; state Exp; branches; next 1.3; 1.3 date 90.10.27.17.31.26; author kemnitz; state Exp; branches; next 1.2; 1.2 date 90.07.30.17.07.18; author kemnitz; state Exp; branches; next 1.1; 1.1 date 90.07.30.13.24.20; author kemnitz; state Exp; branches; next ; desc @Release notes. @ 1.39 log @4.2 final updates @ text @.\" This is -*-nroff-*- with -me macros .\" .\" 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.2 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 .ds PG "\\s-2POSTGRES\\s+2 .ds PV 4.2 .ps 18 .b POSTGRES INSTALLATION INSTRUCTIONS .r .ps 14 .sp 0.25v Release \*(PV .sp 0.25v .ce 0 .sp .\" ---------------- .\" Document Overview .\" ---------------- .sh 0 "Document Overview" .(l Introduction Site Requirements Hardware and Software Distribution Tape Expertise Configuration Programming Environment Disk Requirements Kernel Installing \*(PG Preparation Finding a Good Place for \*(PG Creating the \*(PG Directory Creating the \*(PG User Loading \*(PG Loading \*(PG From Tape Loading \*(PG From a Tar File Kernel Configuration Kernel Reconfiguration for SPARCs Kernel Reconfiguration for DECs (Ultrix only) Compiler Configuration Setup for Solaris 2 Setup for HP-UX Compiling and Installing \*(PG Customization Installing \*(lqbsdinst\*(rq (HP-UX only) Installing \*(lqsolcc\*(rq (Solaris only) Bootstrapping \*(lqbmake\*(rq Building and installing \*(lqlibdl\*(rq (Ultrix only) Installing \*(lqmkldexport\*(rq (AIX only) Compile and Install 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 Mailing List .)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 assistance in fixing problems. This is \fIunsupported\fP software. .\" ---------------- .\" Site Requirements .\" ---------------- .sh 1 "Site Requirements" .lp .sh 2 "Hardware and Software" .lp \*(PG currently has been tested by the \*(PG development team on the following systems: .bu Digital Equipment DECstation 3000 series (Alpha AXP architecture) machines running DEC OSF/1 1.3 and 2.0. .bu Digital Equipment DECstation 3100 and 5000 series (MIPS architecture) machines running Ultrix 4.2A and 4.3A. .bu Hewlett-Packard H-P 9000 Series 700 and 800 (PA-RISC architecture) machines running HP-UX 9.00, 9.01 and 9.03. .bu International Business Machines RS/6000 (POWER architecture) machines running AIX 3.2.5. .bu Sun Microsystems (SPARC architecture) machines running SunOS 4.1.3, (Solaris 1.0.1), SunOS 4.1.3_U1 and Solaris 2.3. .lp 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. .sh 2 "Distribution Tape" .lp These instructions assume you have a \*(PG Version \*(PV distribution tape (in either SCSI cartridge or DEC TK50 cartridge format) or a \*(PG tar file. This release is a source distribution only. The source code is available in tar format over the Internet via anonymous ftp from the site \f(CWs2k-ftp.CS.Berkeley.EDU\fP. Look in the directory \f(CWpub/postgres/postgres-v4r2\fP. The compressed tar file containing the complete source distribution is named \f(CWpostgres-v4r2.tar.Z\fP. .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 recommend 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 "Programming Environment" .lp Some compiler environments must be modified in certain ways. For example, under SunOS 4.x, \*(PG expects things to be configured for BSD by default. If the default on your site is to use the SunOS 4.x System V compiler and libraries then you may have to make some changes to this procedure before compiling \*(PG. Under other systems, you may have to apply patches to your compiler. We will describe such modifications later. .lp To compile this release from sources requires a new version of \f(CWmake\fP which comes from the latest BSD release. A bootstrapping version of the \f(CWmake\fP sources is included with this release and additional instructions are provided below. The new \f(CWmake\fP program is installed as \f(CWbmake\fP to avoid any conflict with your native \f(CWmake\fP. .sh 3 "Disk Requirements" .lp \*(PG requires 50 megabytes of disk space, preferably on a single partition, to compile and install from sources. (As with any program, it may require 2-3 times as much space if you compile the system with optimization turned off and compiler debugging support turned on.) .sh 3 "Kernel" .lp \*(PG makes use of the System V inter-process communication (shared memory and semaphore) operations provided by the operating system. Ultrix requires a properly configured kernel which is in general different than the factory-shipped generic kernel. See the section on kernel configuration for details. 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 patch number CLD-CXO09447. (This patch has been included in Ultrix 4.3a.) .\" ---------------- .\" Installation .\" ---------------- .sh 1 "Installing \*(PG" .lp To install the system you must load the sources into your filesystem and build the system from scratch. To run the compiled programs your kernel may need to be configured to support the shared memory and semaphore operations required by the code. Assuming you have run \*(PG in the past, your machine may already be properly configured. .\" ---------------- .\" 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 First you should locate a disk partition with at least 50 megabytes of free space available for \*(PG. 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 .)l .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: .(l # \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 \*(lqpostgres\*(rq 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 \*(lqadduser\*(rq procedures particular to your platform and site. See your system administration manual for details. .lp The reason we make a \*(lqpostgres\*(rq login is so that when we install the system and create the database directory, everything is owned by this \*(lqpostgres\*(rq user. Then, we start the postmaster when logged in as this \*(lqpostgres\*(rq user, and all the backends are also started by the user \*(lqpostgres\*(rq and are able to access the databases. You can make this work without creating a \*(lqpostgres\*(rq login but this is highly discouraged \(em all \*(PG processes run with this user id, and making yourself the \*(PG user essentially grants all of your database users the ability to become .i you without a password. .lp Note that the restriction about having a \*(lqpostgres\*(rq login with UID 6 was removed in \*(PG Version 4.0.1. .\" ---------------- .\" 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. 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 \*(lqLoading \*(PG from a Tar File.\*(rq .sh 3 "Loading \*(PG from a Tape" .lp Login as \*(lqpostgres\*(rq and change directories to the postgres directory that was created. .lp Run \f(CWtar\fP with the following options .(l % \fBtar xvfp\fP \fI\fP .)l .sp where \fI\fP is the name for your tape device, i.e., \f(CW/dev/rmt0\fP, \f(CW/dev/rst8\fP, etc. .lp The file \f(CWpostgres-v4r2.tar.Z\fP will appear in your \*(PG home directory. 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 \*(lqLoading \*(PG from a Tar File.\*(rq .lp .sh 3 "Loading \*(PG from a Tar File" .lp If you are not logged in as \f(CWpostgres\fP already, do so now. .lp Uncompress the tar file. .(l % \fBuncompress postgres-v4r2.tar.Z\fP .)l .lp A larger file should now be in the \*(PG home directory, and the \*(lq.Z\*(rq ending should be gone, so it is now named \f(CWpostgres-v4r2.tar\fP. .lp Extract \*(PG from the tar file using the following command: .(l % \fBtar xvfp postgres-v4r2.tar\fP .)l .lp Lots of file names and such should appear on the screen. This step may take several minutes. .lp Now do an \f(CWls\fP: .(l % \fBls\fP .)l .lp The output 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 % \fBrm postgres-v4r2.tar\fP .)l .sp .\" ---------------- .\" Configuration .\" ---------------- .sh 2 "Step 3 \- Kernel 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 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 \fBthese steps should be performed by someone with system administration experience\fP. 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 manual pages for \f(CWshmget(3)\fP, \f(CWshmop(3)\fP, \f(CWshmctl(3)\fP, etc. Now proceed to the appropriate section for your machine. .lp .sh 3 "Kernel reconfiguration for SPARCs" .lp We previously suggested that you reconfigure your kernel under SunOS. However, the parameters in the generic kernel of current releases of SunOS ought to suffice. (We never reconfigure our kernels and have not noticed any problems while running several \f(CWpostmaster\fPs at once.) .sh 3 "Kernel reconfiguration for DECs (Ultrix only)" .lp In order to reconfigure your DECstation 3100 or 5000 Ultrix kernel, you will have to become the superuser and add some lines to \f(CW/usr/sys/conf/KERNEL\fP (your kernel config file). .lp Remember that Ultrix 4.3 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. .lp The following lines should be added to \f(CW/usr/sys/conf/KERNEL\fP: .sp .(l .ft CW smmax 256 smseg 12 smbrk 1024 .ft .)l .lp After adding these lines, run \f(CWconfig\fP over the configuration file, install the new kernel (saving a copy of the old kernel first!) and reboot. .sp .\" ---------------- .\" .\" ---------------- .sh 2 "Step 4 \- Compiler Configuration" .lp .sh 3 "Setup for Solaris 2" .lp \*(PG should build without problems using the SunPro SPARCompiler (we used version 3.0). If you do not have the SunPro compiler, you must use a version of the GNU C compiler that fully implements the \f(CW-munaligned-doubles\fP option. You may FTP a suitable set of binaries from \f(CWs2k-ftp.CS.Berkeley.EDU\fP in the directory \f(CWpub/postgres/useful\fP, or you can rebuild your own copy of the GNU C compiler with the required change. The current version as of this writing is 2.5.8, which must be modified with the following one-line patch: .(l M .ft CW --- 1,19 ---- + *** config/sparc/sparc.c Thu Apr 7 09:30:30 1994 + --- config/sparc/sparc.c.orig Thu Apr 7 09:31:35 1994 + *************** + *** 1067,1073 **** + is true, in which case we can only assume that an access is aligned if + it is to an aggregate, it is to a constant address, or the address + involves a LO_SUM. */ + ! else if (! TARGET_UNALIGNED_DOUBLES /* || MEM_IN_STRUCT_P (mem) */ + || CONSTANT_P (addr) || GET_CODE (addr) == LO_SUM) + return 1; + + --- 1067,1073 ---- + is true, in which case we can only assume that an access is aligned if + it is to an aggregate, it is to a constant address, or the address + involves a LO_SUM. */ + ! else if (! TARGET_UNALIGNED_DOUBLES || MEM_IN_STRUCT_P (mem) + || CONSTANT_P (addr) || GET_CODE (addr) == LO_SUM) + return 1; + .ft P .)l We have been told that a later version of the GNU C compiler may incorporate this change (this patch has been sent to both Cygnus Support and the FSF). .sh 3 "Setup for HP-UX" .lp You cannot build \*(PG without the unbundled C compiler. Neither the GNU C compiler nor the (crippled) C compiler that comes with stock HP-UX will work, as both are missing critical compiler options. .lp If you are running HP-UX 9.03, you .b must apply patch PHSS_4307 (or a cumulative patch that supercedes this patch) to your system, as the C preprocessor for HP-UX 9.03 has severe problems. We cannot provide you with this patch; you must obtain it from your H-P support representative. Note that \*(PG should build without problems on 9.01, so you can always build the binaries on a 9.01 system and use them on a 9.03 system. .sp .\" ---------------- .\" Compiling and installing postgres .\" ---------------- .sh 2 "Step 5 \- Compiling and Installing \*(PG" .lp The sources for \*(PG are all under the directory \f(CWsrc/\fP. .sh 3 "Build Step 1: Customization" .lp \f(CWCd\fP into the \f(CWsrc/\fP directory and edit the file \f(CWMakefile.global\fP. You may change the various configuration options here, such as where the \*(PG executable files are installed and where it looks for the database directory. The configuration switches are fairly self-explanatory, but we will go over some of the more commonly-changed options. .lp The PORTNAME option \fBmust\fP be set correctly. By default the PORTNAME is \f(CWultrix4\fP, but .(l aix alpha hpux sparc sparc_solaris ultrix4 .)l are all valid choices. .lp The top-level directory where \*(PG binaries, documentation, header files, libraries, and databases are installed is controlled by the variable POSTGRESDIR. This variable defaults to \f(CW/usr/local/postgres\fP. Whether you change this variable or not, make sure that the directory to which POSTGRESDIR refers exists before proceeding. .lp If you do not want \f(CWbmake\fP installed into \f(CW/usr/local/bin\fP and \f(CW/usr/local/lib\fP, change the values of TOOLSBINDIR and TOOLSLIBDIR and make sure that these directories exist before proceeding. .lp Standards notwithstanding, every system has an \f(CWinstall\fP program with slightly different options and behavior. Our Makefiles assume that \f(CWinstall\fP accepts BSD (as opposed to System V) options. Where possible, we set the INSTALL variable to ensure that the BSD program is called. However, on HP-UX you will have to find a BSD-compatible installation program and set INSTALL to the location of this program. \f(CWbsdinst\fP, which comes with the MIT X Window System distribution (in \f(CWmit/util/scripts\fP), is widely available (we even include it in the \f(CWsrc/tools\fP directory) and works acceptably. The GNU \f(CWinstall\fP program does not. .lp If you are not installing \*(PG using superuser privileges, or you are installing \*(PG without creating a \*(lqpostgres\*(rq user, you may have to set the values of several variables that control the system ownership. For example, \*(lqjaneuser\*(rq who is a member of group \*(lqusers\*(rq may have to set: .(l .ft CW BINGRP= users BINOWN= janeuser LIBGRP= users LIBOWN= janeuser MANGRP= users MANOWN= janeuser .ft .)l to prevent the \f(CWinstall\fP program from complaining. .lp If you absolutely insist on having a \*(PG user other than .q postgres , set the variable POSTGRESLOGIN to the name of that user. .sh 3 "Installing \*(lqbsdinst\*(rq (HP-UX only)" .lp We told you about this above, but in case you missed it, you will have to install \f(CWbsdinst\fP from \f(CWsrc/tools/bsdinst\fP if you don't have it installed already. You can just copy the shell script \f(CWbsdinst.sh\fP into some convenient place (probably \f(CW/usr/local/bin\fP) as \f(CWbsdinst\fP. .sh 3 "Installing \*(lqsolcc\*(rq (Solaris only)" .lp If you are using the GNU C compiler under Solaris 2.3, you must now install the small wrapper in \f(CWsrc/tools/solcc\fP into some convenient place (probably \f(CW/usr/local/bin\fP). You will have to edit this wrapper, changing the line .(l GCCBINDIR=/opt/gnu/bin .)l to point to the directory where you have your (modified) version of \f(CWgcc\fP installed. .lp If you are using the SunPro SPARCompiler, you do not have to install \f(CWsolcc\fP. .sh 3 "Build Step 2: Bootstrapping \*(lqbmake\*(rq" .lp Because the \f(CWbmake\fP program is normally installed into \f(CW/usr/local/{bin,lib}\fP and that directory is usually only writable by root, it will be necessary to temporarily become root to install \f(CWbmake\fP. If you don't have root privilege you can change where \f(CWbmake\fP is installed by changing the value of the TOOLSBINDIR and TOOLSLIBDIR options in \f(CWsrc/Makefile.global\fP, otherwise you will need to \f(CWsu\fP(1) to root. Next make sure that the \f(CWmake\fP program in your PATH environment variable is the system-provided \f(CWmake\fP (usually \f(CW/bin/make\fP) and \fBNOT\fP GNU \f(CWmake\fP (many users have reported problems getting old versions of GNU \f(CWmake\fP to work). .lp \f(CWCd\fP into \f(CWsrc/tools/bmake\fP and type .(l % \fB./Bootstrap\fP \fIportname\fP .)l where \fIportname\fP is the value of PORTNAME (ultrix4, sparc, etc). If you are using the GNU C compiler under Solaris 2.3, type .(l % \fB./Bootstrap\fP \fIportname\fP \fBsolcc\fP .)l to specify the correct compiler. This script should compile and install the \f(CWbmake\fP program and its supporting files, including the \*(PG-related Makefile templates. If all went well you will now be able to use the new program by typing \f(CWbmake\fP, assuming you have \f(CW/usr/local/bin\fP in your shell path. You may have to type \f(CWrehash\fP if you run \f(CWcsh\fP. .sh 3 "Building and installing \*(lqlibdl\*(rq (Ultrix only)" .lp This version of \*(PG uses the \f(CWdlopen(3)\fP interface to implement dynamic function loading. Since there is no such vendor-supplied interface on the Ultrix platform you must build and install a version that we provide. .lp The same previous discussion about being root also holds true here. However, if you cannot become root to install this library, then you will have to change the backend Makefile to look for this library where you have decided to put it using the -L loader flag. .lp To compile and install the library simply \f(CWcd\fP into \f(CWsrc/tools/libdl\fP and type .(l % \fBbmake all install\fP .)l This will build and install the \f(CWlibdl.a\fP library into TOOLSLIBDIR (this is \f(CW/usr/local/lib\fP by default). If your linker/loader doesn't search here by default (it usually does), you may have to \f(CWranlib(1)\fP on it. .sh 3 "Installing \*(lqmkldexport\*(rq (AIX only)" .lp \f(CWCd\fP into \f(CWsrc/tools/mkldexport\fP and type .(l % \fBbmake all install\fP .)l .sh 3 "Build Step 3: Compile and Install" .lp \f(CWCd\fP back to the \f(CWsrc/\fP directory (i.e., \f(CWcd ../..\fP) and type: .(l % \fBbmake all install\fP .)l This builds and installs the entire system. The \f(CWMakefile\fPs contain directives for running all the underlying \f(CWMakefile\fPs in all the directories, so the whole thing should unfold and compile beautifully and install into 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 \f(CWcsh\fP, you could type .(l % \fBbmake all install >& mk.log\fP .)l and if you run \f(CWksh\fP or \f(CWsh\fP, type .(l % \fBbmake all install > mk.log 2>&1\fP .)l This will save the results in the file \f(CWmk.log\fP so you can inspect it later. This would be an ideal opportunity to get some doughnuts and coffee. .sp .sh 2 "Step 5 \- Creating the initial database" .lp \*(PG databases are stored in the directory \f(CW.../postgres/data\fP. 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 the \*(PG programs were loaded into \f(CW/usr/local/postgres/bin\fP). If you run \f(CWcsh\fP, you would put .(l .ft CW set path=(/usr/local/postgres/bin $path) .fT .)l in the \f(CW.login\fP for the \*(PG user. If you run \f(CWsh\fP or \f(CWksh\fP, put .(l .ft CW PATH=/usr/local/postgres/bin:$PATH export PATH .ft .)l in your \f(CW.profile\fP. Then log back in so the change takes effect. .lp Now you can create the initial database by running the following command: .(l % \fBinitdb\fP .)l If that completes successfully, congratulations. .lp Now, to make the system operational you must run the \f(CWpostmaster\fP. The section after \*(lqTesting\*(rq discusses this. .\" ---------------- .\" Testing .\" ---------------- .sh 2 "Step 6 \- Testing" .lp We suggest you run the regression tests to make sure the release was installed successfully. Also, you need to have the \f(CWpostmaster\fP running to run the test, so type the following: .(l % \fBTZ=GMT0\fP % \fBexport TZ\fP % \fBpostmaster -S\fP .)l if you use \f(CWsh\fP or \f(CWksh\fP. If you use \f(CWcsh\fP, type .(l % \fBsetenv TZ GMT0\fP % \fBpostmaster -S\fP .)l instead. The bit about .q TZ is just to make sure that your regression output will be comparable to ours; you don't have to do this every time you start the \f(CWpostmaster\fP. Next, create a new user using the \f(CWcreateuser\fP command (see the Reference Manual). \fBDo not\fP run the regression test script as user \*(lqpostgres\*(rq! .lp Change directories to \f(CWsrc/regress/regress\fP. .(l % \fBcd src/regress/regress\fP .)l Make sure that the \f(CWobj\fP subdirectory is writable by the .q postgres user, as some of the tests involve the .q postgres user copying data into that directory. (We ship it that way, but if you left the .q p flag off of your \f(CWtar\fP command, it will be set according to your umask.) Type the following command to run the test: .(l % \fBbmake clean all runtest\fP .)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 \f(CWobj/regress.out\fP. You can compare this to a sample run that we supply in the file \f(CWsample.regress.out\fP with the following command: .(l % \fBsh checkdiff\fP .)l It may take a little while to run as the regression results are quite large. There will be many differences corresponding to the timestamp lines and occasional lines where object id numbers (OIDs) are different. The \f(CWcheckdiff\fP program attempts to weed out these innocuous differences. If you see any differences not corresponding to timestamps, OIDs or very small differences between floating-point numbers, 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 a front-end program (often the terminal monitor), and .ip \0\0\0\(bu the backend server. .lp Users are expected to use the terminal monitor for direct access to the database. The terminal monitor sends commands to the \f(CWpostmaster\fP which forwards commands to a backend. .sh 2 "The \*(PG Postmaster" .lp The \f(CWpostmaster\fP is a process which manages communication between the a front-end program such as the terminal monitor and a \*(PG backend. Without a running \f(CWpostmaster\fP, the front-end program will not be able to connect to a backend. In general, the \f(CWpostmaster\fP must be running for you (or others) to run any of the normal \*(PG commands. Always start the \f(CWpostmaster\fP when logged in as the special \*(lqpostgres\*(rq user, otherwise the system will not be able to access the database files. To start it, type .(l % \fBpostmaster &\fP .)l .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 % \fBcreatedb\fP \fIdatabase\fP .)l Now we will run the monitor: .(l % \fBmonitor\fP \fIdatabase\fP .)l .(l .ft CW Welcome to the POSTGRES terminal monitor Go * .ft I 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. .ft CW * \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 I Okay, this worked, too. Now we'll quit. .ft CW * \fB\eq\fP .ft CW % .ft R .)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 \f(CWpostmaster\fP when it 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 \*(PG as a multiuser system, running the backend can result in locking failures and corrupt databases, as the \f(CWpostmaster\fP handles shared resources such as semaphores and shared memory. In short: never do this if there is a \f(CWpostmaster\fP running. In addition, when using the terminal monitor, returned tuples are displayed more usefully and input is buffered better. The backend should only be used interactively 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 database 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 reindexdb \- rebuild system catalog indices after disaster shmemdoc \- shared memory buffer pool doctor vacuum \- database vacuum cleaner icopy \- inversion filesystem file management utility 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 \f(CW.../lib/libpq.a\fP is created when you install the 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 \f(CW/usr/local/lib\fP or \f(CW/usr/lib\fP so that the C compiler can reference it with \f(CW-lpq\fP. If you do not, you will have to use the \f(CW-L\fP directive to the \f(CWcc\fP and \f(CWld\fP commands so that they can find \f(CWlibpq.a\fP. .sh 2 "Postgres Header Files" .lp The directory \f(CW.../include\fP contains copies of most of the header files that front-end applications might need. You can compile a frontend program with the \f(CW-I\fP directive to \f(CWcc\fP as illustrated in the following example: .(l % \fBcc -I/usr/local/postgres/include -o\fP \fIfoo foo.c\fP \fB-lpq\fP .)l .lp Occassionally a front-end program source might reference header files from the \*(PG source that were not copied into the \f(CWinclude\fP directory. If your front-end program complains about not being able to find header files, either add the missing header files to the \f(CWinclude/\fP directory and notify us of the problem, or just point the \f(CW-I\fP compiler directive directly into the source as was done in the past. E.g., .(l % \fBcc -I/usr/local/postgres/src/backend -o\fP \fIfoo foo.c\fP \fB-lpq\fP .)l If you do this, you may need to add the following \f(CW#define\fPs in your source to set the PORTNAME \(em add them prior to any \f(CW#include\fPs: .(l .ft CW #define PORTNAME_\fIPORTNAME\fP .ft .)l For example, if you are running on the ultrix4 port, you would put .(l .ft CW #define PORTNAME_ultrix4 .ft .)l in your program, or if you're running the sparc port put .(l .ft CW #define PORTNAME_sparc .ft .)l in your program source. .sh 2 "Wisconsin Benchmark Database" .lp In \f(CW.../postgres/src/regress/bench\fP are files which are the queries used in the \*(PG 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, \f(CWcd\fP to that directory and type .(l % \fBbmake runtest\fP .)l .lp .sh 2 "Minimal Installation" .lp It is the intention that everything below the \f(CWsrc/\fP directory can be removed. Sometimes however, as stated earlier, the \f(CWinclude/\fP 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. Should you really wish to remove the source to reclaim space you could always copy all the header files from the backend into the include directory (preserving the directory structure of course). .\" ---------------- .\" Documentation .\" ---------------- .sh 1 "Documentation" .lp Plain text and PostScript versions of the manual pages and documents are available in the directories \f(CWman/\fP and \f(CWdoc/\fP at the top level. To recreate these documents, there are corresponding directories in \f(CWsrc/{man,doc}\fP. They are currently configured to require \f(CWgroff\fP and friends, but you may be able to change the \f(CWMakefile\fP to use other facilities if you have them. If you change directories to \f(CWman/\fP and \f(CWdoc/\fP and type: .(l % \fBbmake\fP % \fBbmake install\fP .)l in each, it will format and install the documents into the corresponding destination directories. In general, recreating documents from their source is very difficult due to differences in macro packages and formatting programs (in short, good luck!). .\" ---------------- .\" Miscellaneous .\" ---------------- .sh 1 "Miscellaneous" .sh 2 "Bug reports" .lp If you find a bug in \*(PG, please send mail to .(l .ft CW bug-postgres@@postgres.Berkeley.EDU .ft .)l or .(l .ft CW uunet!ucbvax!postgres!bug-postgres .ft .)l describing as precisely as possible the command that caused the problem, concise instructions on how to repeat the bug, and a script showing the bug. If possible, a stack trace (generated using a debugger such as \f(CWdbx\fP or \f(CWgdb\fP) should also be provided. (The backend program will leave its core dumps in the directory PGDATA\f(CW/base/your_database\fP, where \*(lqyour_database\*(rq is the name of your database.) However, see the next section. .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 provide support in a research environment. .lp If you do want to talk directly to the \*(PG group, electronic mail is the only method. We can be reached via the Internet as .(l .ft CW post_questions@@postgres.Berkeley.EDU .ft .)l or .(l .ft CW uunet!ucbvax!postgres!post_questions .ft .)l Please be aware that this was the last release of \*(PG from the University of California, and for all practical purposes there is no longer a \*(PG group. However some of us may still be reading mail for a while and it is likely that some correspondence will occur. .lp .sh 2 "Postgres Mailing List" .lp A mailing list for \*(PG announcements and discussion is available for anyone who is interested. If you wish to subscribe to this mailing list, send mail to .(l .ft CW postgres-request@@postgres.Berkeley.EDU .ft .)l or .(l .ft CW uunet!ucbvax!postgres!postgres-request .ft .)l with \f(CWADD\fP as the subject. Note that mail sent to this address is processed .b electronically . (Deletion requests are handled by sending mail to the same address with subject \f(CWDEL\fP.) .lp The mailing list itself is called .(l .ft CW postgres@@postgres.Berkeley.EDU .ft .)l or .(l .ft CW uunet!ucbvax!postgres!postgres .ft .)l and all mail sent to this address will be will be routed to the mailing list membership. As of the time of this release, this mailing list was being distributed to over 600 sites around the world, so please do .b NOT send administrative requests to this address. If you have any problems with the mailing list, send mail to \f(CWpost_questions\fP. @ 1.38 log @remove "and higher" @ text @d22 1 a22 1 .\" POSTGRES version 4.1 setup instructions d61 1 a61 2 Hardware Software d65 1 a65 1 Operating System d73 9 a81 5 Loading \*(PG From Tape Loading \*(PG From a Tar File Configuration Kernel Reconfiguration for Sparcs Kernel Reconfiguration for DEC's d83 7 d135 1 a135 1 .sh 2 "Hardware" d141 1 a141 1 machines running Alpha OSF/1 1.3. d147 1 a147 1 machines running HP-UX 9.00 and 9.01. d152 2 a153 3 Sun Microsystems (SPARC architecture) machines running SunOS 4.1.2 (Solaris 1.0.1) and 4.1.3. (\*(PG will \fBnot\fP run on machines running SunOS 5.x (Solaris 2.x)). a159 9 .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 patch number CLD-CXO09447. (This patch has been included in Ultrix 4.3a.) .sh 2 "Software" d163 7 a169 9 tape (in either SCSI cartridge or DEC TK50 cartridge format) or a \*(PG tar file. The previous version of \*(PG came with pre-compiled binaries for the SPARC and Ultrix platforms, however this release is a source distribution only. The source code is available in tar format over the Internet via anonymous ftp from the site s2k-ftp.CS.Berkeley.EDU. Look in the directory \f(CWpub/postgres/postgres-v4r2\fP. The compressed tar file containing the complete source distribution is named \f(CWpostgres-v4r2.tar.Z\fP. d192 1 a192 1 .sh 3 "Operating System" d194 7 a200 4 \*(PG expects things to be configured for BSD by default. If the default on your site is to use the SunOS System V compiler and libraries then you may have to make some changes to this procedure before compiling \*(PG. d203 5 a207 5 make which comes from the latest BSD release. A bootstrapping version of the make sources is included with this release. The make program is installed using the name \f(CWbmake\fP to avoid any conflict with your native make. d210 4 a213 2 \*(PG requires 50 megabytes of disk space, preferably on a single partition, to compile and install from sources. d218 8 a225 3 SunOS and Ultrix require a properly configured kernel which is in general different than the factory-shipped generic kernel. See the section on kernel configuration for details. d316 1 a316 1 .sh 2 "Step 2 - Loading \*(PG" d346 1 a346 1 .sh 2 "Loading \*(PG from a Tar File" d390 1 a390 1 .sh 2 "Step 3 - Kernel Configuration" d417 1 a417 1 .sh 3 "Kernel reconfiguration for Sparcs" d424 1 a424 1 .sh 3 "Kernel reconfiguration for DECs" d432 1 a432 1 the DEC supplied patch at this point if you have not already. d449 58 d509 1 a509 1 .sh 2 "Compiling and Installing \*(PG" d528 1 d548 7 a554 11 For example, the \f(CWinstall\fP that comes with SunOS and Ultrix accept BSD options. However, the default OSF/1, HP-UX and AIX installation programs do not. You can set the INSTALL variable to control which program is called. On OSF/1, set INSTALL to \f(CW/bin/installbsd\fP. On AIX, use \f(CW/usr/ucb/install\fP instead of \f(CW/bin/install\fP. On HP-UX, you will have to find a BSD-compatible installation program and set INSTALL to the location of this program. \f(CWbsdinst\fP, which comes with the MIT X Window System distribution (in \f(CWmit/util/scripts\fP), is widely available (we include it in the \f(CWsrc/tools\fP directory) and works acceptably. The GNU \f(CWinstall\fP program does not. d576 1 a576 1 .sh 3 "On HP-UX only: installing bsdinst" d583 14 d617 6 a622 1 This should compile d625 1 a625 1 will now be able to use the new make program by typing \f(CWbmake\fP, d628 1 a628 1 .sh 3 "On Ultrix only: building and installing libdl" d650 1 a650 1 .sh 3 "On AIX only: installing mkldexport" d680 1 a680 1 .sh 2 "Creating the initial database" d715 1 a715 1 .sh 2 "Step 4 - Testing" d724 1 a724 1 % \fBpostmaster &\fP d729 1 a729 1 % \fBpostmaster &\fP d764 8 a771 9 It may take a little while to run as the regression results are quite large. There will be many differences corresponding to the timestamp lines and occasional lines where object id numbers (OIDs) are different. The \f(CWcheckdiff\fP program attempts to weed out these innocuous differences. If you see any differences not corresponding to timestamps or OIDs, there may be a problem. Have your local \*(PG expert take a look at it. d957 1 a957 1 .sh 2 "Postgres header files" d968 1 a968 1 from the postgres source that were not copied into the include d1067 1 a1067 1 the name of your database.) @ 1.37 log @fix instructions for regress (need to clean) @ text @d131 1 a131 1 machines running Alpha OSF/1 1.3 and higher. d134 1 a134 1 machines running Ultrix 4.2 and higher. d137 1 a137 1 machines running HP-UX 9.00 and higher. d140 1 a140 1 running AIX 3.2.3 and higher. d143 1 a143 1 (Solaris 1.0.1) and higher. (\*(PG will \fBnot\fP run on machines @ 1.36 log @make bsdinst thing more explicit(letters of flame should be ok) @ text @d325 1 a325 1 % \fBtar xvf\fP \fI\fP d353 1 a353 1 % \fBtar xvf postgres-v4r2.tar\fP d518 2 a519 1 shell script into some convenient place (probably \f(CW/usr/local/bin\fP). d644 1 a644 1 if you use \f(CWsh\fP or \f(CWksh\fP, or d649 1 a649 1 if you use \f(CWcsh\fP. The bit about d661 9 a669 2 Type the following command to run the test: d671 1 a671 1 % \fBbmake runtest\fP d688 1 a688 2 If you see any differences not corresponding to timestamps or OIDs, d1052 1 a1052 1 distributed to over 650 sites around the world, so please do @ 1.35 log @setting TZ so regress spew is nicer @ text @d513 6 @ 1.34 log @removed sunos kernel stuff (i mean, it's not like we do it) gnu make works now (but who needs the headache) mkldexport on aix also aix note about /usr/ucb/install @ text @d168 1 a168 1 the internet via anonymous ftp from the site s2k-ftp.CS.Berkeley.EDU. d228 1 a228 1 be properly configured to run. d521 2 a522 1 in \f(CWsrc/Makefile.global\fP, otherwise you will need to su(1) to root. d526 1 a526 1 noted problems getting GNU \f(CWmake\fP to work). d539 1 a539 1 .sh 3 "On Ultrix only, building and installing libdl" d557 2 a558 1 TOOLSLIBDIR (/usr/local/lib by default). If your linker/loader d561 1 a561 1 .sh 3 "On AIX only, installing mkldexport" d621 1 a621 1 Now, to make the system operational you must run the postmaster. d630 1 a630 1 Also, you need to have the postmaster d633 2 d637 9 a645 2 .lp if you haven't already. d647 1 a647 1 (see the reference manual). \fBDo not\fP run the regression test d698 2 a699 1 sends commands to the postmaster which forwards commands to a backend. d702 1 a702 1 The postmaster is a process which manages communication between the d704 1 a704 1 Without a running postmaster, d706 2 a707 2 In general, the postmaster must be running for you (or others) to run any of the normal \*(PG commands. Always start the postmaster when a712 5 Now you can leave the postmaster running if you wish to keep the database system accessible. In general, when the postmaster is running, the system is running. When it is not running, none of the frontend programs will work. d797 1 a797 1 This process is started by the postmaster when the postmaster d812 5 a816 4 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 d818 1 a818 1 The backend is used interactively primarily during debugging. d1037 3 a1039 2 will be routed to the mailing list membership. This list is distributed to over 500 sites around the world, so please do @ 1.33 log @update for 4.2 release @ text @d134 1 a134 1 machines running Ultrix 4.1 and higher. d136 2 a137 2 Hewlett-Packard H-P 9000/700 series (PA-RISC architecture) machines running HP-UX 8.07 and higher. d163 1 a163 1 tape (in either 1600bpi 9-track, SCSI cartridge, or DEC TK50 cartridge d169 2 a170 2 Look in the directory pub/postgres/postgres-v4r2. The compressed tar file containing the complete source distribution d183 1 a183 1 so we advise d296 6 a301 1 \*(lqpostgres\*(rq login but this is highly discouraged. d411 5 a415 87 In order to reconfigure Sun or Sparc kernel, you will have to become the superuser and add some lines to \f(CW/usr/sys/conf/KERNEL\fP (your kernel config file) and \f(CW/usr/sys/conf/param.c\fP (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 \f(CW/usr/sys/conf/KERNEL\fP: .sp .(l .ft CW 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) .ft .)l .sp .lp At Berkeley, we substitute the line: .(l .ft CW options EMOREIPCS # more semaphores and shared memory (for 8M) .ft .)l .lp with the line: .(l .ft CW options TTMOREIPCS # more semaphores and shared memory (for 32M) .ft .)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 \f(CW/usr/sys/conf/param.c\fP: .sp .(l .ft CW /* * 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 SHMSIZE 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 SHMSIZE 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 */ .ft .)l .lp After adding these lines, run \f(CWconfig\fP over the config file, install the new kernel (saving a copy of the old kernel first!) and reboot. .sp d481 2 a482 2 For example, the \f(CWinstall\fP that comes with AIX, SunOS and Ultrix accept BSD options. However, the default OSF/1 and HP-UX installation d485 1 d489 2 a490 1 \f(CWmit/util/scripts\fP), is widely available and works acceptably. d509 4 d524 2 a525 2 \f(CW/bin/make\fP) and \fBNOT\fP GNU \f(CWmake\fP. GNU \f(CWmake\fP is \fBguaranteed not to work\fP. d531 1 a531 1 where \fIportname\fP is the value of PORTNAME (ultrix, sparc, etc). d540 4 a543 4 This version of \*(PG uses the dlopen() interface to implement dynamic function loading. Since there is no such vendor supplied interface on the Ultrix platform you must build and install a version that we provide you with. d551 1 a551 1 simply \f(CWCd\fP into \f(CWsrc/tools/libdl\fP and type d558 7 a564 2 move it to /usr/lib. If you do move it, be sure to run ranlib(1) on it. d637 1 a637 1 script as user \*(lqpostgres\*(rq! If you do, certain tests will fail. d828 1 a830 1 pg_copytree \- copy the source tree (probably shouldn't be shipped) @ 1.32 log @updated for hpux/aix/alpha @ text @a78 1 Running the Pre-installed \*(PG System d164 8 a171 11 format) or a \*(PG tar file. This release comes with a pre-installed version of \*(PG ready to run for the 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 compatibility 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 \f(CWpostgres.berkeley.edu\fP. d203 2 a204 2 version of the make sources is included with this release, as is a precompiled binary with its configuration files. The make program a210 2 If you run the pre-installed system, you only need 25 megabytes to hold the executables and sources. d223 3 a225 4 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 d227 2 a228 8 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. d242 1 a242 1 You should locate a disk partition with a243 18 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. d264 10 d283 1 a283 1 Finally, we need to create a user called \*(PG whose d309 1 a309 3 a distribution tape or a \*(PG tar file (available via anonymous FTP from \f(CWpostgres.berkeley.edu\fP). .lp d318 1 a318 1 3. Run \f(CWtar\fP with the following options d326 2 a327 2 The file \f(CWpostgres-v4r1.XXX.tar.Z\fP will appear in your \*(PG home directory, where XXX is the name of the platform. You may need a335 2 For the purpose of this discussion, the \*(PG tar file will be called \f(CWpostgres-v4r1.XXX.tar.Z\fP. d339 1 a339 1 % \fBuncompress postgres-v4r1.XXX.tar.Z\fP d344 1 a344 1 \f(CWpostgres-v4r1.XXX.tar\fP. d348 1 a348 1 % \fBtar xvf postgres-v4r1.XXX.tar\fP d371 1 a371 1 % \fBrm postgres-v4r1.XXX.tar\fP d377 1 a377 1 .sh 2 "Step 3 - Configuration" a517 70 .\" Running the pre-installed system .\" ---------------- .sh 2 "Running the pre-installed \*(PG system" .lp Assuming you have loaded the system into \f(CW/usr/local/postgres\fP, there is very little else to do. Add \f(CW/usr/local/postgres/bin\fP to your shell path. If you run \f(CWcsh\fP, you would put .(l .ft CW set path=(/usr/local/postgres/bin $path) .ft .)l in the \f(CW.login\fP for the \*(lqpostgres\*(rq user. If you run \f(CWsh\fP or \f(CWksh\fP, put .(l .ft CW PATH=/usr/local/postgres/bin:$PATH export PATH .ft .)l in your \f(CW.profile\fP. Then log back in so the change takes effect. Now run the following command .(l % \fBnewbki\fP .)l This will reset the userid of the special \*(PG user of the database to have the proper value. Even though the \f(CWnewbki\fP command allows you to enter a login name, you should select the default value of \f(CWpostgres\fP. .lp After doing this, you may wish to install the precompiled version of \f(CWbmake\fP into \f(CW/usr/local/bin\fP. This will allow you to recompile \*(PG right away without bootstrapping \f(CWbmake\fP. To do this, \f(CWcd\fP into the directory called \f(CWlocal\fP. You will see two directories and a README. Become the superuser and do the following: .(l # \fBcp bin/bmake /usr/local/bin\fP # \fBmkdir /usr/local/lib /usr/local/lib/mk\fP \fI(you may get an error if this directory already exists - ignore it)\fP # \fBcp lib/mk/* /usr/local/lib/mk\fP .)l .lp If you installed \*(PG somewhere other than \f(CW/usr/local/postgres\fP, 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 \f(CW/private/packages/postgres\fP. If you run \f(CWcsh\fP, put the following in the \f(CW.login\fP for the \*(PG user .(l .ft CW setenv PGDATA /private/packages/postgres/data .ft .)l If you run \f(CWsh\fP or \f(CWksh\fP, put the following in \f(CW.profile\fP: .(l .ft CW PGDATA=/private/packages/postgres/data export PGDATA .ft .)l This will instruct the postmaster and backends to look in that directory for the databases. .lp You can now skip to the section called \*(lqCreating the initial database.\*(rq .sp .\" ---------------- d522 1 a522 8 The sources for \*(PG are all under the directory \f(CWsrc/\fP. The first step is to install the new \f(CWbmake\fP program. By the way, you can look at the previous section entitled \*(lqRunning the pre-installed system\*(rq in the paragraph about \f(CWbmake\fP, and just copy the pre-compiled \f(CWbmake\fP to \f(CW/usr/local/{bin,lib}\fP 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: d546 1 a546 1 \f(CW/private/devel/postgres\fP. Whether you change this variable or d586 8 a593 1 Before proceeding, make sure that the \f(CWmake\fP program in your d602 2 a603 1 where \fIportname\fP is the value of PORTNAME. This should compile d609 22 d641 1 a641 1 compile beautifully and install to the target directory. Should d661 1 a661 1 \*(PG was loaded into \f(CW/usr/local/postgres\fP). d693 2 a694 2 was installed successfully. You must have installed the \f(CWbmake\fP program to run the test. Also, you need to have the postmaster d700 1 d703 1 a703 1 script as user \*(lqpostgres\*(rq! d705 1 a705 2 Change directories to \f(CWsrc/regress/regress\fP. Type the following commands: d708 4 d721 1 a721 1 % \fBdiff sample.regress.out obj/regress.out\fP d723 3 a725 1 Unfortunately you will see many differences corresponding to d727 3 a729 2 are different. We regret that we do not have a more sophisticated script for weeding out these innocuous differences at this time. If d745 1 a745 1 the terminal monitor, d757 1 a757 1 user's terminal monitor and a \*(PG backend. d759 1 a759 1 the terminal monitor will not be able to connect to a backend. d911 1 a911 1 install the system (or on the pre-installed system). d916 1 a916 1 you may wish to copy this file to d923 1 a923 1 The directory \f(CW.../include\fP contains copies of all the header d931 5 a935 5 This feature of copying just the necessary header files into \f(CW.../include\fP was incorporated right before we produced the release and has not had sufficient testing. If your frontend programs complain about not being able to find header files, either d947 6 a952 1 #define PORTNAME ultrix4 d956 1 a956 1 for Ultrix, or a958 1 #define PORTNAME sparc d962 1 a962 4 for SPARCs. We're sorry for any inconvenience this may cause, and fully intend that the \f(CWinclude/\fP directory be more rigorously tested in the next release. d977 2 a978 1 be removed, however we didn't have time to test this. Specifically, d981 4 a984 2 remove the source. But if you'd like to try it out, we'd love to know if it works for you. d1003 3 a1005 1 destination directories. d1041 1 a1041 1 group, electronic mail is strongly preferred. d1054 5 a1058 2 We can also be reached at (510) 643-6448, Monday through Friday, between 1 and 4 PM Pacific Time. @ 1.31 log @changed sunos kernel hacking instructions (SHMPOOL was a sunos 3.5-ism, the sunos 4 #define is SHMSIZE). fixed marc's phone #. postgres.cs.berkeley.edu -> postgres.berkeley.edu made the font settings consistent noted that you should not run regress as postgres. suggested you save a copy of your old kernel before installing your hacked kernel :-) @ text @d43 1 a43 1 .ds PV 4.1 d128 24 a151 10 \*(PG currently has been tested by the \*(PG development team on Sun Microsystems SPARC architecture machines running SunOS 4.1 (Solaris 1.x). (\*(PG will \fBnot\fP run on machines running SunOS 5 (Solaris 2.x)). \*(PG also runs on DECstation 3100s and 5000s 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. d163 13 a175 18 These instructions assume you have a \*(PG Version \*(PV distribution tape (in either 1600bpi 9-track, SCSI cartridge, or DEC 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 compatibility 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 \f(CWpostgres.berkeley.edu\fP. No sources-only tar file is currently available. d219 5 a223 5 \*(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. d316 2 a317 3 the databases. Although you can make this work without creating a \*(lqpostgres\*(rq login, we provide no support for doing so (you are, as they say, \*(lqon your own\*(rq). d407 1 a407 1 section on configuring a kernel in the SunOS or DEC system administration d419 9 a427 10 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 manual pages for \f(CWshmget()\fP, \f(CWshmop()\fP, \f(CWshmctl()\fP, etc. Now proceed to the appropriate section for your machine. d622 1 a622 1 \f(CW/usr/local/{bin,lib}\fP if you want and skip step 2) in this d625 1 a626 2 - build step 1: customization - .lp d628 59 a686 11 \f(CWMakefile.global\fP. By default the PORTNAME is \f(CWultrix4\fP. Change this to \f(CWsparc\fP if you are running on a SPARC-based machine. Also, if you do not want \f(CWbmake\fP installed into \f(CW/usr/local/bin\fP and \f(CW/usr/local/lib\fP, 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. d688 4 a691 1 - build step 2: bootstrapping the new bmake program - d695 1 a695 1 % \fBmake -f Makefile.boot\fP d697 7 a703 10 You may get warning messages during this bootstrapping process about \*(lqillegal combination of pointer and integer\*(rq \(em just ignore them. This should compile and install the \f(CWbmake\fP 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 \f(CWbmake\fP, assuming you have \f(CW/usr/local/bin\fP in your shell path. You may have to type \f(CWrehash\fP if you run \f(CWcsh\fP. .lp - build step 3: compile and install the world - d792 1 a792 1 the timestamp lines and occasional lines where object id numbers (OID's) d795 1 a795 1 you see any differences not corresponding to time stamps or OIDS, d813 1 a813 1 the backend. d1097 1 a1097 1 commitment to support in a research environment. @ 1.30 log @oops - ultrix 4.3 has the kernel bug, not 4.2 @ text @d1 1 d42 2 d50 1 a50 1 Release 4.1 a56 1 .ds PG "\\s-2POSTGRES\\s+2 d97 1 a97 1 \*(PG BBS d117 4 a120 5 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. d129 9 a137 12 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. d140 6 a145 6 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. d149 3 a151 3 These instructions assume you have a \*(PG Version 4.1 distribution tape (in either 9 track, SCSI cartridge, or TK50 cartridge format) d160 1 a160 1 that the sources be rebuilt from scratch to rule out any compatability d163 4 a166 3 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. d192 1 a192 1 If the default on your site is to use the SunOS SysV compiler d281 1 d284 1 d299 1 a299 1 This can be done using the "adduser" procedures particular to your d302 11 a312 9 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"). d322 2 a323 2 a distribution tape or a \*(PG tar file (available via anonymous ftp from postgres.cs.berkeley.edu). d327 1 a327 1 section "Loading \*(PG from a Tar File". d330 1 a330 1 Login as postgres and change directories to the postgres directory d333 4 a336 3 3. Run "tar" with the following options .lp % tar xvf d338 2 a339 2 where is the name for your tape device, i.e., /dev/rmt0, /dev/rst8, etc. d341 4 a344 4 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. d346 1 a346 1 Proceed to the next section "Loading \*(PG from a Tar File". d352 1 a352 1 \f(CWpostgres-v4r1.XXX.tar.Z\fP d356 1 a356 1 % uncompress postgres-v4r1.XXX.tar.Z d359 3 a361 3 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 d365 1 a365 1 % tar xvf postgres-v4r1.XXX.tar d371 1 a371 1 Now do an "ls": d373 1 a373 1 % ls d376 1 a376 1 The output of the ls should look something like: d388 1 a388 1 % rm postgres-v4r1.XXX.tar d418 2 a419 2 you may want to consult the Man pages for \fIshmget()\fR, \fIshmop()\fR, \fIshmctl()\fR, etc. Now proceed to the appropriate d424 4 a427 4 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 d432 1 a432 1 The following lines should be added to /usr/sys/conf/KERNEL: d435 1 d440 1 d446 1 d448 1 d453 1 d455 1 d462 2 a463 1 Also add the following lines to the \fItop\fR of /usr/sys/conf/param.c: d466 1 d485 1 a485 1 #define SHMPOOL 1536 /* max total shared memory system wide (in Kbytes) */ d496 1 a496 1 #define SHMPOOL 8192 /* max total shared memory system wide (in Kbytes) */ d504 1 d507 3 a509 4 After adding these lines, run config over the config file, install the new kernel, and reboot. d514 8 a521 2 you will have to become root and add some lines to /usr/sys/conf (your kernel config file). a522 2 The following lines should be added to /usr/sys/conf/KERNEL: .sp d524 5 a528 3 smmax 256 smseg 12 smbrk 1024 d531 3 a533 8 After adding these lines, run .i config over the configuration file, install the new kernel, and reboot. .lp Also, remember that Ultrix 4.3 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. d540 3 a542 3 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 d544 1 d546 1 d548 2 a549 1 in the .login for the postgres user. Or if you run sh or ksh, put d551 1 d554 1 d556 2 a557 2 in your .profile. Then log back in so the change takes effect. Now run the following command d559 1 a559 1 % newbki d562 3 a564 4 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... d567 19 a585 16 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 d587 1 d589 1 d591 2 a592 1 or if you run sh or ksh, put the following in .profile d594 1 d597 1 d602 2 a603 1 You can now skip to the setion called "Creating the initial database". d610 8 a617 7 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: d621 6 a626 6 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. d636 1 a636 1 Cd into src/tools/bmake and type d638 1 a638 1 % make -f Makefile.boot d640 8 a647 9 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. d651 2 a652 1 Cd back to the src/ directory (i.e. cd ../..) and type d654 1 a654 1 % bmake all install d656 2 a657 2 This builds and installs the entire system. The Makefiles contain directives for running all the underlying Makefiles d661 1 a661 1 of the compile in a file. If you run csh(1), you could type d663 1 a663 1 % bmake all install >& mk.log d665 1 a665 1 and if you run ksh(1) or sh(1), type d667 1 a667 1 % bmake all install > mk.log 2>&1 d669 1 a669 1 This will save the results in the file "mk.log" so you d671 1 a671 1 some donuts and coffee. d675 1 a675 1 \*(PG databases are stored in the directory .../postgres/data. d679 2 a680 2 \*(PG was loaded into /usr/local/postgres). If you run csh, you would put d682 1 d684 1 d686 2 a687 1 in the .login for the \*(PG user. Or if you run sh or ksh, put d689 1 d692 1 d694 1 a694 1 in your .profile. Then log back in so the change takes effect. d697 1 a697 1 command. d699 1 a699 1 % initdb d704 1 a704 1 The section after "Testing" discusses this. d711 3 a713 3 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: d715 1 a715 1 % postmaster & d718 6 a723 2 Change directories to src/regress/regress and type the following bmake command: d725 2 a726 2 % cd src/regress/regress % bmake runtest d731 2 a732 2 file "obj/regress.out". You can compare this to a sample run that we supply in the file "sample.regress.out" with the following d735 1 a735 1 % diff sample.regress.out obj/regress.out d737 1 a737 1 Unfortunatly you will see many differences corresponding to d773 1 a773 1 logged in as the special "postgres" user, otherwise the system will d776 1 a776 1 % postmaster & d780 1 a780 1 database system accessable. In general, when the postmaster d793 1 a793 1 createdb \fIdatabase\fR d797 1 a797 1 % monitor \fIdatabase\fR d801 1 a801 1 Welcome to the C POSTGRES terminal monitor a804 1 .ft d806 1 a806 1 \fI a811 1 \fR d813 2 a814 2 *\fBretrieve (u.usename, u.usesysid) from u in pg_user \eg\fP a852 1 .ft d854 5 a858 4 .lp Okay, this worked, too. Now we'll quit. .lp *\fB\eq\fP a859 2 I live to serve you. .ft d861 1 d880 1 a880 1 We recommend using the terminal monitor; if you are using Postgres as a d896 1 a896 1 createdb \- creates new \*(PG databases d899 2 a900 2 destroyuser \- delete a user from the datasbe system ipcclean \- frees up garbage shared memory from failed backends d907 2 a908 1 pg_copytree \- copy te source tree (probably shouldn't be shipped) d921 1 a921 1 The file .../lib/libpq.a is created when you d928 4 a931 1 /usr/lib so that the C compiler can reference it with -lpq. d934 1 a934 1 The directory .../include contains copies of all the header d936 2 a937 2 a frontend program with the -I cc directive as illustrated in the following example: d939 1 a939 1 cc -I/usr/local/postgres/include -o foo foo.c -lpq d942 2 a943 1 This feature of copying just the necessary header files into .../include d945 1 a945 1 has not had sufficient testing. It your frontend programs d947 9 a955 3 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. d957 1 a957 5 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 d960 1 d962 1 a962 1 for ultrix, or d964 1 d967 1 d969 1 d971 2 a972 1 that the include/ directory be more rigorously tested in the next release. d975 2 a976 2 In .../postgres/src/regress/bench are files which are the queries used in the Postgres d978 2 a979 3 "basic" relational performance using B-Tree indices on nontrivial amounts of data. To run the benchmark, type cd to that directory and type d981 1 a981 1 bmake runtest d986 1 a986 1 It is the intention that everything below the src/ directory can d988 1 a988 1 the include/ directory may not have all the necessary files to d991 1 a991 1 works for you.... :) d996 9 a1004 7 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 d1006 2 a1007 2 % bmake % bmake install d1017 1 a1017 1 If you find a bug with \*(PG, d1020 4 a1023 1 \0\0\0\0\0bug-postgres@@postgres.Berkeley.EDU d1025 4 a1028 1 \0\0\0\0\0(ucbvax!postgres!bug-postgres) d1030 7 a1036 4 describing as precisely as possible the command that caused the problem, instructions on how to repeat the bug, and a script showing the bug. d1045 1 a1045 1 If you do want to talk directly to the Postgres d1049 4 a1052 1 \0\0\0\0\0post_questions@@postgres.Berkeley.EDU d1054 4 a1057 1 \0\0\0\0\0(ucbvax!postgres!post_questions) d1059 1 a1059 2 We can also be reached at (510) 642-7520, Monday through Friday, d1062 3 a1064 2 .sh 2 "Postgres BBS" A mailing list for Postgres announcements and discussion d1068 9 a1076 1 \0\0\0\0\0postgres-request@@postgres.Berkeley.EDU d1078 5 a1082 2 with "Add" as the subject. Note that mail sent to this address is processed .b electronically. d1086 9 a1094 1 \0\0\0\0\0postgres@@postgres.Berkeley.EDU d1097 6 a1102 1 will be routed to the mailing list membership. @ 1.29 log @type typo @ text @d47 1 a47 1 C-Only Release 4.1 d69 5 a73 5 Finding a good place for \*(PG Creating the postgres directory Creating the \*(lqpostgres\*(rq user Loading \*(PG from tape Loading \*(PG from a tar file d75 5 a79 5 Kernel reconfiguration for sparcs Kernel reconfiguration for DEC's Running the pre-installed \*(PG system Compiling and installing \*(PG Creating the initial database d87 3 a89 3 Installing LIBPQ, the \*(PG frontend library \*(PG header files Wisconson benchmark database d95 1 a95 1 Postgres BBS d109 2 a110 2 rights for any derived work on the condition that it obtain an educational license to the derived work. d119 1 a119 1 This is *unsupported* software. d127 1 a127 1 \*(PG currently has been tested by the Postgres development team on Sun d129 1 a129 1 running SunOS 4.1 and higher. Postgres is also d141 1 a141 1 The DECstation version requires a kernel which allows 4 megabytes of d143 1 a143 2 .lp The original release of Ultrix 4.2 has a kernel bug that causes d149 1 a149 1 .sh 2 "Distribution tape" d156 5 a160 3 for the two platforms we officially support. This is a test to see if our users can make use of the pre-installed system, thus avoiding having to compile from scratch for those in a rush to get things going. Should d165 2 a166 2 The tar version of the ultrix release is "postgres-v4r1.ultrix.tar.Z" and the sparc release is "postgres-v4r1.sparc.tar.Z" available via d175 1 a175 1 \*(PG be familiar with the various system administration d201 1 a201 1 is installed using the name "bmake" to avoid any conflict with d214 1 a214 1 than the factory-shipped "generic" kernel. d250 1 a250 1 if you loaded the release into the directory "/usr/local/postgres", d253 1 a253 1 setup to look for the database directory in "/usr/local/postgres/data", d257 1 a257 1 from /usr/local/postgres to the place you really loaded the system. d266 1 a266 1 path of the directory you will install postgres in. d283 1 a283 1 so we decide to create the postgres directory there... d292 1 a292 1 .sh 2 "Creating the \*(lqpostgres\*(rq user" d294 3 a296 3 Finally, we need to create a user called \*(lqpostgres\*(rq whose shell is /bin/csh. Though not necessary, it is convenient to make the home directory of the \*(lqpostgres\*(rq user d346 1 a346 3 If you are not logged in as \*(PG already, log in as \*(PG. Make sure your current working directory is the \*(PG directory that was created, and put the \*(PG tar file there if it is not already. d348 1 a348 1 postgres-v4r1.XXX.tar.Z d404 1 a404 1 If you try to run a postgres backend process on a machine without enough d518 1 a518 1 Also, remember that Ultrix 4.2 has a kernel bug that causes the d543 1 a543 1 This will reset the userid of the special postgres user of the database to d545 1 a545 1 name, you should select the default value of "postgres". It allows a d547 1 a547 1 that a special user called "postgres" even exists -- but not yet... d561 1 a561 1 If you installed postgres somewhere other than /usr/local/postgres, everything d563 1 a563 1 the special postgres login. Lets assume you installed postgres in d565 1 a565 1 the following in the .login for the postgres user d601 1 a601 1 At this point you can also change where the postgres executable d616 1 a616 1 its supporting files, including the postgres related d627 1 a627 1 % bmake install d636 1 a636 1 % bmake install >& mk.log d640 1 a640 1 % bmake install > mk.log 2>&1 d652 1 a652 1 postgres was loaded into /usr/local/postgres). d657 1 a657 1 in the .login for the postgres user. Or if you run sh or ksh, put d706 1 a706 1 there may be a problem. Have your local postgres expert take a look d736 1 a736 1 run any of the normal postgres commands. Always start the postmaster when d774 1 a774 1 query: list the names and user ids of the postgres users. d863 3 a865 3 createdb \- creates new postgres databases createuser \- add a new user to the postgres system destroydb \- destroys postgres databases d891 1 a891 1 You use this library if you want to execute Postgres queries @ 1.28 log @4.0.1 -> 4.1 @ text @a296 1 of the directory we loaded postgres @ 1.27 log @fixups @ text @d21 1 a21 1 .\" POSTGRES version 4.0.1 setup instructions d47 1 a47 1 C-Only Release 4.0.1 @ 1.26 log @new version @ text @a56 1 Document Overview d65 1 a65 2 Disk Partition Swap Partition a66 1 Lisp a67 1 Overview d69 2 a70 2 Finding Space for \*(PG Creating /usr/postgres d72 2 a73 2 Loading Loading \*(PG d75 5 a79 5 Kernel reconfiguration Configuring \*(PG Compiling Compiling \*(PG Creating the initial database a80 1 Testing \*(PG d88 2 a89 2 Performance Tuning Demo Database a91 4 Printing the Manual and Reference If you do not have a Postscript printer Printing the Technical Reports and Tutorials If the directory has a makefile a93 1 Known Bug List d102 1 a102 1 .pp d114 1 a114 1 .pp d124 1 a124 1 .pp d126 1 a126 1 .pp d140 1 a140 1 .pp d143 1 a143 1 .pp d151 1 a151 1 .pp d156 1 a156 1 This release comes with a pre-installed version of \*PG ready to run d162 1 a162 1 problems between the system we compiled on here at Berkeley and your own. There d168 2 a169 2 .pp Once a site is properly configured and \*(PG is properly installed, d181 1 a181 1 .pp d190 1 a190 1 .pp d195 1 a195 1 .pp d202 6 a207 7 .sh 3 "Disk Partition" .pp \*(PG requires 45 megabytes of disk space, preferably on a single partition. If you don't have enough space, it is still possible to compile and run \*(PG but you will have to modify the installation scripts. d209 1 a209 1 .pp d219 1 a219 1 .pp d237 1 a237 1 .pp d240 1 a240 1 superuser authority. d245 1 a245 1 .pp d260 1 a260 1 .pp a265 1 Write it down in preparation for the next step. d292 1 a292 1 .pp d294 2 a295 2 shell is /bin/csh. It is not necessary, but is convenient, to make the home directory of the \*(lqpostgres\*(rq user to be d300 1 a300 1 .pp d305 2 a306 2 this postgres user and are able to access the databases. You can probably make this work d308 2 a309 2 having a postgres login with uid 6 was removed a while ago), but we will not provide support for this (you are, as they say, "on your own"). d314 1 a314 1 .pp d321 1 a321 1 .pp d326 1 a326 1 .pp d329 1 a329 1 .pp d331 1 a331 1 .pp d336 1 a336 1 .pp d341 1 a341 1 .pp d343 1 a343 1 .pp d345 1 a345 1 .pp a349 1 .pp d351 1 a351 1 .pp d353 1 a353 1 .pp d355 2 a356 1 .pp a358 1 .pp d360 1 a360 1 .pp d362 1 a362 1 .pp d364 2 a365 1 .pp d368 1 a368 1 .pp d370 4 a373 1 .pp d376 1 d380 7 a387 2 .pp At this point you have loaded the \*(PG files. d393 1 a393 1 .pp d399 1 a399 1 This task requires superuser authority and should d403 1 a403 1 .pp d408 1 a408 1 .pp d414 1 a414 1 .pp d419 1 a419 1 .pp d421 1 a421 1 .pp d495 1 a495 1 .pp d502 1 a502 1 .pp d514 1 a514 1 .pp d519 1 a519 1 .pp d528 1 d545 1 a545 1 This will reset the userid of special postgres user of the database to d549 2 a550 2 that there even exists a special user called "postgres" -- but not yet... .pp d562 1 a562 1 .pp d569 1 a569 1 setenv PGDATA /private/packages/data d573 1 a573 1 PGDATA=/private/packages/data d578 2 a579 2 .pp You are now ready to go to the setion called "Creating the initial database". a583 2 .sh 2 "Compiling and installing \*(PG" .pp d585 1 a585 1 .pp d593 1 a593 1 .pp d595 1 a595 1 .pp d601 2 a602 7 these directories exist. Also, note it is not possible to move the bmake(1) library files after the bmake(1) executable is built since the pathname to the lib/ directory is hardcoded into the executable. If you wish to move the library files elsewhere, you have to change TOOLSLIBDIR in the source and goto step 2) which makes and installs bmake(1). .pp d606 3 a608 1 .pp d610 1 a610 1 .pp d624 1 a624 1 .pp d626 1 d648 2 a649 2 .sh 3 "Creating the initial database" .pp d665 1 a665 1 .pp d672 1 a672 1 .pp d679 1 a679 1 .pp d685 1 a685 1 % postmaster % d687 1 a687 1 .pp d694 1 a694 1 .pp d696 1 a696 1 time to run. WHen it's done, the output of the test is in the d715 1 a715 1 .pp d732 1 a732 1 .pp d751 1 a751 1 .pp d754 2 a755 2 .pp Lets assume \fIatabase\fR is the name of the database you want to use. d823 1 a823 1 .pp d825 1 a825 1 .pp d833 1 a833 1 .pp d858 1 a858 1 .pp d888 1 a888 1 .pp d898 1 a898 1 .pp d906 3 a908 3 .pp This feature of copying just the necessary header files into .../include was done right before we built the release and d919 1 a919 1 .( d922 1 a922 1 .) d924 1 a924 1 .( d927 1 a927 1 .) d931 1 a931 1 .pp d941 1 a941 1 .pp d943 1 a943 1 .pp d948 1 a948 1 removed. But if you'd like to try it out, we'd love to know if it d964 1 a964 1 .) d972 1 a972 1 .pp d985 1 a985 1 .pp d991 1 a991 1 .pp d1003 1 a1003 1 .pp d1013 1 a1013 1 .pp @ 1.25 log @changes for 4.0.1 @ text @d52 1 a52 1 .tm Document Overview d109 1 a109 1 .tm Introduction d131 1 a131 1 .tm Site Requirements d138 3 a140 7 Microsystems 3/xx family of processors with SunOS 3.4, or 3.5, and 4.0, and Sparc architecture machines (Sparcstation and Sun 4) running SunOS 4.0 and higher. Postgres is also supported on DECstations 3100's and 5000's running Ultrix 4.0 and higher. Tested but unsupported ports for DECstation Ultrix lower than 4.0 are included. These ports are unsupported for the following reasons: the old Ultrix dynamic loader is quite buggy. d153 6 a159 3 .pp This implementation of \*(PG is completely in C. The distribution contains no Lisp or C++ code. d162 1 a162 1 These instructions assume you have a \*(PG Version 4.0.1 d166 11 d187 1 a187 1 steps require superuser authority on the system, d206 6 a211 8 One exception to this rule is that we use Sun's SysV-compatible .i make to build the system. This is the version of .i make that is installed in both the BSD and SysV environments on Suns, so this should pose no problems on these platforms. We have no problems on DECstations either. d222 1 a222 1 provided by SunOS, DEC Ultrix, and Dynix, d227 1 a227 1 .tm Installation d231 13 a243 15 \*(PG installation consists of the following steps: .ip \0\0\0\(bu Preparation .ip \0\0\0\(bu Loading .ip \0\0\0\(bu Configuration .ip \0\0\0\(bu Compilation .ip \0\0\0\(bu Testing .lp Each of these steps is described below. It is advised that you read over each of these steps carefully before beginning the installation. d245 1 a245 1 .tm Preparation d258 12 a269 5 at least 45 megabytes of free space available for \*(PG. If you haven't any single partition with 25 megabytes free, you might have to spread apart the \*(PG directories across several partitions, and glue them together with symbolic links. d272 2 a273 4 Once you have located a partition with enough space, create a directory called .q postgres someplace on this partition. d287 1 a287 1 /dev/xy1g 221279 138365 60786 69% /public d293 2 a294 2 /public looks like a good place (it has 60 megs free) so we decide to create the postgres directory there... d296 1 a296 1 # \fBcd /public\fR d300 1 a300 1 /public/postgres a302 16 .sh 2 "Creating /usr/postgres" .pp \*(PG expects to be .i logically installed in a directory called .q /usr/postgres , so you must create a symbolic link from /usr/postgres to whatever directory you created in the previous step. In our example, we would now type: .sp .(l # \fBln -s /public/postgres /usr/postgres\fR .)l d306 4 a309 1 shell is /bin/csh and whose home directory is /usr/postgres. a311 2 .lp .b Note: d313 9 a321 20 Due to a bug in this release, the "postgres" user must be user 6 (six). Otherwise, you may encounter problems with backends hanging, etc. See the .b Release .b Notes (described in Section 6.2 of this document) for instructions on how to get around this problem if it causes problems at your site. If it is not convienent for you to make the "postgres" user userid 6, complete the below instructions on .b Loading \*(PG, but read the .b Release .b Notes notes on how to get around this problem .b before continuing on to the .b Configuration section. .pp d323 1 a323 1 .tm Loading d327 1 a327 2 After completing step 1 (Preparation), you should be ready to load d331 2 a332 1 a distribution tape or a \*(PG tar file. d339 2 a340 1 Login as postgres. d342 1 a342 1 3. Run "tar" with the "extract, verbose, file" options: d349 2 a350 1 The file "postgres-v4r0r1.tar.Z" will appear in your \*(PG home directory. d354 1 a354 1 Please proceed to the section "Loading \*(PG from a Tar File". d359 2 a360 2 Make sure your current working directory is the \*(PG home directory, and that the \*(PG tar file is there. d363 1 a363 1 postgres-v4r0r1.tar.Z d367 1 a367 1 % uncompress postgres-v4r0r1.tar.Z d372 1 a372 1 postgres-v4r0r1.tar d374 1 a374 2 Extract \*(PG from the tar file, using the "extract, verbose, file" options: d376 1 a376 1 % tar xvf postgres-v4r0r1.tar d385 3 a387 2 COPYRIGHT bench/ demo/ newconf/ src/ README doc/ ref/ test/ sample/ video/ a390 1 Other directories will be created by the installation process. d393 1 a393 1 .tm Configuration d423 1 a423 1 .sh 3 "Kernel reconfiguration for Suns and Sparcs" d522 60 d584 1 a584 1 .tm Compiling d586 3 a588 1 .sh 2 "Configuring \*(PG" d590 31 a620 43 This release of \*(PG may require some configuration. For performance reasons, Postgres is by default compiled with the optimizer enabled and internal debugging assertions disabled. If you plan to modify Postgres, you may want to enable debugging (note that this will take Postgres up to about 50 megs from about 45 megs otherwise), and enable internal debugging assertions. .pp To enable compiler directives, read the file ./newconf/CONFIG/README for instructions on what to change. Now to edit the configuration file, .(l .sp 0.5v % \fBcd /usr/postgres/newconf/CONFIG\fP .sp 0.5v % \fBvi config.mk.\fP .)l .pp where .i is the following: .(l dec \- DS3100 running Ultrix LOWER than 4.0 ultrix4 \- DS3100, 5000, 5500, etc. running Ultrix 4.0 or higher sun \- Sun 3 running SunOS 3.4 or 3.5 sunos4 \- Sun 3 running SunOS 4.0 or higher sparc \- Sparcstation or Sun 4 .)l The .i only thing we recommend changing is the GCFLAGS variable. Remember the .b port .b name used here as it is necessary for Step 4. .pp .sh 2 "Step 4 - Compiling and Installing \*(PG" Now you are ready to install Postgres. To do so, simply execute the following commands: .(l % \fBcd ~postgres/newconf\fR % \fBsetenv POSTGRESHOME ~postgres\fR % \fB./Make install\fR d622 9 d632 22 a653 36 .lp .i Make .i install will ask you for the port you wish to use. Use the port name that you used in .b Configuring \*(PG. You will also be asked for the name of the object tree directory; the default is ~postgres/obj.. (throughout the rest of this document obj. refers to the object tree directory). This step will take from about 40 minutes on Sparc II or DEC 5000 class machines to several hours on Sun 3's. The POSTGRESHOME environment variable is the home directory of the Postgres user. In the course of the installation process, the Postgres .b bin and .b data directories will be created and populated. .pp .i Make is a C shell script that runs .i make with Makefiles that are constructed on the fly. If you have problems at this point, it is possible that your .i \&.cshrc file does strange things \*- changes directories, sets or unsets environment variables, and so on. .pp You should see no errors during this phase, except possibly for warnings (which can be ignored) when compiling the output of .i yacc and .i lex. d656 10 a665 6 \*(PG databases are stored in the directory ~postgres/data. After you have compiled \*(PG, you will need to create the initial database. To do this, type d667 7 a673 22 % \fBsetenv POSTGRESHOME ~postgres\fR % \fB~postgres/bin/postmaster &\fR % \fB~postgres/bin/createdb postgres\fR % \fBkill %~postgres/bin/postmaster\fR .)l This will create the bootstrap template database, from which the database .q postgres will be generated. The .i postmaster program will be discussed later - however, you must have it running in order to run .i createdb. If several users wish to use \*(PG, we advise you to create additional databases, one for each user. This can be done by running .i createdb with the username as the first argument. For example, to create a database for the user \*(lqbill\*(rq, type d675 1 a675 1 % \fB~postgres/bin/createdb bill\fR d677 4 d682 1 a682 1 .tm Testing d685 15 a699 1 .sh 3 "Testing \*(PG" d701 5 a705 5 After compiling the \*(PG backend and support programs and creating the initial database, you should test your compilation with the following. Commands you should type appear in \fBboldface\fP. d707 1 a707 75 \fB% ~postgres/bin/postgres\fR .ft CW ---debug info--- Quiet = f Noversion = f override = f DatabaseName = [postgres] ---------------- **** Transaction System Active **** InitPostgres().. POSTGRES backend interactive interface $Revision: 1.24 $ $Date: 1992/07/20 18:33:04 $ StartTransactionCommand() at Thu Nov 2 15:43:35 1989 .ft > \fBretrieve (pg_user.all)\fP .ft CW now in make_Var relation = pg_user, attr = usecatupd vnum = 1 ... .ft \fIlots of debugging output...\fP .ft CW ---- parser outputs : ((1 retrieve nil (("pg_user" 86 0 nil nil ))0 nil )((#S(resdom :resno 1 :restype 19 :reslen 16 :resname "usename" :reskey 0 :reskeyop 0)#S(var ... .ft \fIlots more debugging output...\fP .ft CW ProcessQuery() at Thu Nov 2 15:43:50 1989 blank 1: usename (typeid = 19, len = 16, byval = f) 2: usesysid (typeid = 21, len = 2, byval = t) 3: usecreatedb (typeid = 16, len = 1, byval = t) 4: usetrace (typeid = 16, len = 1, byval = t) 5: usesuper (typeid = 16, len = 1, byval = t) 6: usecatupd (typeid = 16, len = 1, byval = t) ---- 1: usename = "postgres" (typeid = 19, len = 16, byval = f) 2: usesysid = "6" (typeid = 21, len = 2, byval = t) 3: usecreatedb = "t" (typeid = 16, len = 1, byval = t) 4: usetrace = "t" (typeid = 16, len = 1, byval = t) 5: usesuper = "t" (typeid = 16, len = 1, byval = t) 6: usecatupd = "t" (typeid = 16, len = 1, byval = t) ---- 1: usename = "goh" (typeid = 19, len = 16, byval = f) 2: usesysid = "234" (typeid = 21, len = 2, byval = t) 3: usecreatedb = "t" (typeid = 16, len = 1, byval = t) 4: usetrace = "t" (typeid = 16, len = 1, byval = t) 5: usesuper = "t" (typeid = 16, len = 1, byval = t) 6: usecatupd = "t" (typeid = 16, len = 1, byval = t) ---- ... CommitTransactionCommand() at Thu Nov 2 15:43:51 1989 StartTransactionCommand() at Thu Nov 2 15:43:51 1989 .ft \fIIt works!\fP \fI The above response is an example of the raw output generated by the backend. Your actual output may be slightly different. Normally, you would use a terminal monitor to talk to the backend instead. To leave the backend, type : \fR > ^D % d709 7 d718 1 a718 1 .tm Running d733 2 a734 1 Users are expected to use the terminal monitor. a736 3 If you just completed step 3, then you have already been introduced to the \*(PG backend, so we'll talk about the other two processes now. d743 13 a755 8 To start the postmaster, type: .(l % \fBcd ~postgres/bin\fR % \fBsetenv POSTGRESHOME ~postgres\fR % \fBpostmaster &\fR .)l Here we are using the default parameters for the postmaster. For more details, consult the Reference. d760 4 a763 2 To start a terminal monitor, type d765 1 a765 1 % \fBmonitor \fR a766 2 .pp \fIDatabase\fR is the name of the database you want to use. d769 3 d813 2 d849 1 a849 1 % \fB~postgres/bin/postgres\fR \fIdatabase\fR d858 2 a859 1 as semaphores and shared memory. d870 3 a872 2 createdb \- creates new postgres databases createdb.sh \- creates new postgres databases - old version d874 3 a876 1 ipcclean \- frees up garbage shared memory from failed backends d878 1 a878 2 pg_id \- gets user id's for createdb pg_uid \- gets postgres user id for initializing the template database d880 11 a890 1 shmemdoc \- shared memory buffer pool doctor d895 2 a896 2 The file ~postgres/obj./libpq.a is created when you compile the system. d903 1 a903 6 To do this, type: .(l # \fBcp ~postgres/obj./libpq.a /usr/lib\fR .)l .sh 2 "Demo Database" d905 31 a935 16 In ~postgres/demo are files to be included by the terminal monitor to set up a demo database. Additional files demonstrate inheritance, historical queries, abstract data types, and various other features of \*(PG. A description of the demo database can be found in ~postgres/demo/DEMO-README. .sh 2 "Video Demo Database" .pp In ~postgres/video are files that were used in the 1991 Postgres SIGMOD video. These files demonstrate both the instance level and query rewrite rule systems, views, versions, and spatial queries using R-Tree indices. A description of the video database can be found in ~postgres/video/VIDEO-README. d938 2 a939 1 In ~postgres/bench are files which are the queries used in the Postgres d942 2 a943 15 of data. Instructions for running the benchmark are in ~postgres/bench/WISC-README. .pp .sh 2 "Minimal Installation" .pp The directories (in ~postgres) necessary for a minimal running system are: .(l bin/ the binary programs comprising \*(PG data/ support files and user created databases files/ database initialization scripts .)l When compiled using the "default" compilation options as shipped, (ie optimization and no debugging), these directories will take up about 5 Mbytes. The following directories are necessary if Postgres is to ever be recompiled. d945 1 a945 3 newconf/ the \*(PG configuration directory obj./ compiled \*(PG object files src/ \*(PG source files d948 1 a948 11 When compiled using the "defaults", these directories will use about 16 Mbytes. Additional Postgres directories are as follows: .(l demo/ demo database scripts video/ video demo database scripts bench/ Wisconsin benchmark database scripts sample/ Sample LIBPQ application doc/ postgres technical reports and the \*(PG Manual ref/ \*(PG Reference source .)l d950 6 a955 4 These directories take up about 2 Mbytes, and can be reduced to about 200 Kbytes if the Postscript files in doc and ref are deleted. .pp We do not recommend deleting these unless absolutely necessary. d957 1 a957 1 .tm Documentation d960 13 a972 111 .sh 2 "Printing the Manual" .pp The \*(PG manual is now in the file .(l \fB~postgres/doc/manual.me\fR .)l This manual replaces the old tutorials, which are no longer distributed. It is recommended that you read this manual before making extensive use of \*(PG. A Postscript version of this manual is in .(l \fB~postgres/doc/psdump/manual.ps\fR .)l .pp .sh 2 "Printing the Reference" .pp The Reference is the document which details the exact syntax used by \*(PG commands, and provides interface definitions for LIBPQ and large objects. It is intended as a reference and should not be read cover to cover. .pp If you have a Postscript printer, you can print the Reference by changing directory to the .(l \fB~postgres/ref\fR .)l directory, where you will find a Postscript file called \fBref.t\fR. This file can be simply sent to the printer in whatever fashion your site uses to print Postscript files. .pp If you do not have a Postscript printer, or you have font problems, etc., the \fBref\fR directory contains a /bin/sh script called "genref". Edit this script and set the appropriate parameters for printing at your site in this script, and then execute it by typing .(l % \fBgenref\fR .)l This script will not actually try to send the job to the printer - rather it will create the \fBref.t\fR output file. You can then print the manual by sending this file directly to the printer with the regular printing commands used by your site. .pp If \fBgenref\fR fails, you may not have the \fBgrn\fR preprocessor. This preprocessor for troff allows pictures drawn with the \fBgremlin\fR graphics editor to be printed using a "troff" command. A script called \fBeatgrn\fR is provided, which will cause \fBgenref\fR to ignore \fBgrn\fR directives and print anyway - this will result in the reference being printed without illustrations. There is only one illustration, so this should not be too much of a problem. .pp .sh 3 "If you do not have a Postscript printer" .pp If you do not have a Postscript printer, change the \fBpsroff\fR command in the \fBgenref\fR script to the text formatting command you use at your site, typically \fBnroff\fR, \fBtroff\fR, or \fBditroff\fR. As stated above, use the \fBeatgrn\fR script if you do not have \fBgrn\fR. Output suitable for a line-printer can be created using \fBnroff\fR. .pp .sh 2 "Printing the Technical Reports and Tutorials" .pp Postscript versions of the Postgres technical reports, tutorials, and release notes are in the directory \fB~postgres/doc/psdump\fR. Some files are not included in Postscript form and are simply regular files - read the file \fB~postgres/doc/README\fR for details. .pp The /bin/sh script \fB~postgres/doc/print\fR contains site-specific printing parameters, and understands the file extension protocol used in the \fBdoc\fR directory. Once you set the site-specific parameters for printing in this script, you should be able to print all the files in the \fBdoc\fR easily, by executing .(l % \fBprint \fR .)l from the \fB~postgres/doc\fR directory. .pp Unlike the \fBgenref\fR script described above, this script will send the job directly to the printer. If you do not have the \fBgrn\fR utility described above, you should use the \fBeatgrn\fR script here as well. For technical reports which require \fBmake\fR, continue to the following section. .pp .sh 3 "If the directory has a makefile" .pp A couple of the technical reports use makefiles to generate their printable versions rather than the \fBprint\fR script. If the subdirectory has a makefile, you will have to change the site-specific parameters in the makefile, run .(l % \fBmake\fR .)l and then it will either print or create a printable file. Note that if the makefile uses \fBgrn\fR and you do not have access to this utility, you can use the \fBeatgrn\fR script here as well. .sh 2 "The 4.0.1 Release Notes" .pp The Postgres 4.0.1 Release Notes are in the file \fB~postgres/doc/release4.0.1.me\fR. Before working extensively with Postgres, you should read this file to find new features, known bugs, and other useful information about this release. .pp As described above, you can print this file by typing .pp .(l % \fBprint ~postgres/doc/release4.0.1.me\fR .)l d974 1 a974 1 .tm Miscellaneous a989 6 .sh 2 "Known Bugs List" .pp A Known Bugs List with suggested workarounds is maintained on the machine \fBpostgres.berkeley.edu\fR in the file \fBpub/postgres-v4r0r1.bugs\fR. The Internet address of this machine is \fB128.32.149.1\fR, and if you cannot access Postgres, this file can be sent to you via e-mail. d1006 1 a1006 1 We can also be reached at (415) 642-7520, @ 1.24 log @add missing .(l @ text @d21 1 a21 1 .\" POSTGRES version 2 setup instructions d47 1 a47 1 C-Only Release 3.1 d142 3 a144 7 Tested but unsupported ports for DECstation Ultrix lower than 4.0 and Sequent Symmetry machines running Dynix are included. These ports are unsupported for the following reasons: the old Ultrix dynamic loader is quite buggy, and the standard .i make on the Sequent Symmetry cannot compile Postgres. a156 5 To compile the Sequent Symmetry port, you will have to obtain a System V Release 3 compatible .i make. Consult your Sequent representative for details. d163 1 a163 1 These instructions assume you have a \*(PG Version 3 d203 1 a203 3 problems on DECstations either. However, we have had a great deal of difficulty on Sequent Symmetry machines, so we advise that you obtain a Sun-compatible make for these platforms. d363 1 a363 1 The file "postgres-v3r1.tar.Z" will appear in your \*(PG home directory. d376 1 a376 1 postgres-v3r1.tar.Z d380 1 a380 1 % uncompress postgres-v3r1.tar.Z d385 1 a385 1 postgres-v3r1.tar d390 1 a390 1 % tar xvf postgres-v3r1.tar a536 17 .sh 3 "Kernel reconfiguration for Sequent Symmetry machines" .pp In order to reconfigure your kernel, you will have to become root and add some lines to /usr/sys/conf (your kernel config file) .sp The following line should be added to /sys/conf/KERNEL: .sp .(l options SVSEMA .)l .pp After adding this line, run config over the config file, install the new kernel, and reboot. .sp a567 1 seq \- Sequent Symmetry running Dynix d682 1 a682 1 $Revision: 1.23 $ $Date: 1991/12/02 10:16:38 $ d896 3 d1078 1 a1078 1 .sh 2 "The 3.1 Release Notes" d1080 2 a1081 2 The Postgres 3.1 Release Notes are in the file \fB~postgres/doc/release3.1.me\fR. d1089 1 a1089 1 % \fBprint ~postgres/doc/release3.1.me\fR d1111 1 a1111 1 \fBpostgres.berkeley.edu\fR in the file \fBpub/postgres-v3r1.bugs\fR. The @ 1.23 log @3.0 -> 3.1 @ text @d711 1 a711 1 $Revision: 1.22 $ $Date: 91/12/02 04:15:58 $ d823 1 @ 1.22 log @*** empty log message *** @ text @d47 1 a47 1 C-Only Release 3.0 d374 1 a374 1 The file "postgres-v3r0.tar.Z" will appear in your \*(PG home directory. d387 1 a387 1 postgres-v3r0.tar.Z d391 1 a391 1 % uncompress postgres-v3r0.tar.Z d396 1 a396 1 postgres-v3r0.tar d401 1 a401 1 % tar xvf postgres-v3r0.tar d711 1 a711 1 $Revision: 1.21 $ $Date: 91/08/18 07:51:47 $ d1103 1 a1103 1 .sh 2 "The 3.0 Release Notes" d1105 2 a1106 2 The Postgres 3.0 Release Notes are in the file \fB~postgres/doc/release3.0.me\fR. d1114 1 a1114 1 % \fBprint ~postgres/doc/release3.0.me\fR d1136 1 a1136 1 \fBpostgres.berkeley.edu\fR in the file \fBpub/postgres-v3r0.bugs\fR. The @ 1.21 log @fixed a couple of problems. @ text @d97 1 a97 1 Printing the Reference Manual d711 1 a711 1 $Revision: 1.20 $ $Date: 91/08/18 05:41:18 $ d810 1 a810 1 details, consult the Reference Manual. d993 2 a994 2 doc/ postgres technical reports and tutorials ref/ \*(PG Reference Manual source d1005 1 a1005 1 .sh 2 "Printing the Reference Manual" d1007 19 a1025 1 If you have a Postscript printer, you can print the reference manual by d1050 1 a1050 1 print anyway - this will result in the reference manual being printed without @ 1.20 log @fixed confusing detail. @ text @d711 1 a711 1 $Revision: 1.19 $ $Date: 91/08/18 05:12:25 $ a910 2 Note that the program called "backend" is not really the backend; it is a program used by createdb to initialize databases. a916 1 backend \- used by initdb to create system classes d919 1 a919 1 createdb.sh \- creates new postgres databases - old version d953 1 d960 1 @ 1.19 log @fixed bogus wording on release notes @ text @d602 4 a605 1 GCFLAGS variable. Remember the port name used here for Step 3. d607 1 a607 1 .sh 2 "Step 3 - Compiling and Installing \*(PG" d619 5 a623 2 will ask you for the port you wish to use. Use the same port as in Step 2. You will also be asked for the name of the object tree directory; d711 1 a711 1 $Revision: 1.18 $ $Date: 91/08/18 03:39:50 $ @ 1.18 log @added blurb on bad userid @ text @d330 5 a334 1 See the release notes for instructions on how to get around this problem d339 4 a342 1 but read the installation notes on how to get around this problem d705 1 a705 1 $Revision: 1.17 $ $Date: 91/08/18 02:38:57 $ @ 1.17 log @oops - changed name from postscript to psdump @ text @d325 16 d698 1 a698 1 $Revision: 1.16 $ $Date: 91/08/18 02:31:52 $ @ 1.16 log @cleaned up discussions about installation, docs, etc. @ text @d682 1 a682 1 $Revision: 1.15 $ $Date: 91/08/16 04:21:21 $ d1020 3 a1022 2 Postscript versions of the Postgres technical reports and tutorials are in the directory \fB~postgres/doc/postscript\fR. Some files are not @ 1.15 log @more updates for the 3.0 release. @ text @d96 5 d103 1 d368 1 a368 1 % uncompres postgres-v3r0.tar.Z d682 1 a682 1 $Revision: 1.14 $ $Date: 91/03/09 05:00:09 $ d765 1 a765 1 If you just completed step 4, d974 1 a974 1 .tm Miscellaneous d976 1 a976 1 .sh 1 "Miscellaneous" d979 2 a980 1 You can print the Postgres reference manual by changing directory to the d982 1 a982 1 \fBref\fR d984 8 a991 3 directory. There you will find a /bin/sh script called "genref". Set all the appropriate parameters for printing at your site in this script, and then run it by typing d996 3 a998 9 it will create an output file called "ref.t". You can then print the manual by sending this file directly to the printer with the "lpr" command. The manual is about 80 pages of single-sided text. If you do not have the GRN preprocessor for troff, substitute the GRN command in the script with the name "eatgrn", which is a script which is in the same directory, or print the Postscript file "ref.t" which is provided in the "postscript" subdirectory. The "grn" program allows pictures drawn in the GREMLIN graphics editor to be printed using a "troff" command, so if you use "eatgrn", the illustrations in the manual will not be printed. d1000 8 a1008 4 If you do not have a Postscript printer, change the "psroff" command to the nroff command you use at your site, typically "nroff", "troff", or "ditroff". As stated above, use the eatgrn script if you do not have GRN. Output suitable for a line-printer can be created using "nroff". d1010 8 d1019 13 a1031 2 You can print the Postgres technical reports and tutorials by changing directory to the a1032 6 \fBdoc\fR .)l subdirectory. There you will find a /bin/sh script called "print". After you change the site-specific parameters in this script, you can print most of these files, with the exception of those requiring "make", by typing .(l d1035 3 a1037 1 from this directory. Unlike the "genref" script described above, this d1039 4 a1042 3 "grn" utility described above, you should use the "eatgrn" script here as well. For technical reports which require "make", go to the following section. d1044 4 a1047 2 A couple of the technical reports use makefiles rather than the "print" script. If the subdirectory has a makefile, you will have d1054 19 a1072 1 makefile uses GRN, you can use the eatgrn script here as well. d1086 6 @ 1.14 log @changed a bit of stuff. @ text @d47 1 a47 1 C-Only Release 2.1 a90 1 Periodic Maintenance d145 1 a145 1 and you will require at least 30 megabytes of disk space d166 1 a166 1 These instructions assume you have a \*(PG Version 2 d211 1 a211 1 \*(PG requires 30 megabytes of disk space, d257 1 a257 1 at least 30 megabytes of free space available for \*(PG. d345 1 a345 1 The file "postgres-v2r1.tar.Z" will appear in your \*(PG home directory. d358 1 a358 1 postgres-v2r1.tar.Z d362 1 a362 1 % uncompres postgres-v2r1.tar.Z d367 1 a367 1 postgres-v2r1.tar d372 1 a372 1 % tar xvf postgres-v2r1.tar d381 2 a382 2 COPYRIGHT demo/ newconf/ src/ README doc/ ref/ d543 5 a547 5 For performance reasons, you may want to compile Postgres with the optimizer enabled, floating point coprocessors enabled, etc. The default is to use the default options. Also, if you plan to modify Postgres, you may want to enable debugging (note that this will take Postgres up to about 50 megs from about 30 megs otherwise). a548 6 \fB WARNING!! DO NOT ENABLE COMPILER OPTIMIZATION ON SUN 4's OR SPARCS - POSTGRES WILL CRASH YOUR MACHINE IF COMPILED THIS WAY!! (This appears to be due to a kernel problem with the shared memory functions.) \fR .pp d550 1 a550 1 look in the file ./newconf/CONFIG/README d564 1 a564 1 ultrix4 \- DS3100 running Ultrix 4.0 d566 1 a566 1 sunos4 \- Sun 3 running SunOS 4.0 d580 1 d590 9 a598 2 obj. refers to the object tree directory). This step will take at least an hour and may take several hours on Sun 3's. d626 4 a629 4 % \fBsetenv POSTGRESHOME ~postgres % ~postgres/bin/postmaster & % ~postgres/bin/createdb postgres\fR % kill %~postgres/bin/postmaster d676 1 a676 1 $Revision: 1.13 $ $Date: 91/03/07 03:45:05 $ d837 1 a837 1 | plai | 3665 | a889 1 vacuumd \- vacuum cleaner daemon a892 9 .\" ---------------- .tm Periodic Maintenance .\" ---------------- .sh 2 "Periodic Maintenance" .pp The database log files in ~postgres/data/base/*/PG_DBLOG and ~postgres/data/PG_SYSLOG can grow in size. Periodic truncation of these files is recommended. .pp d912 1 a912 1 to setup a demo database. d920 12 d942 2 a943 2 When compiled using the "defaults", (ie no optimization and no debugging), these directories will take up about 8 Mbytes. d956 3 d964 1 a964 1 200 Kbytes if the Postscript files are deleted. @ 1.13 log @Updates for 2.1 @ text @d597 1 a597 1 an hour and may take several hours on diskless Sun 3's. d635 3 a637 1 program will be discussed later. d675 1 a675 1 $Revision: 1.12 $ $Date: 91/01/15 18:00:07 $ a799 5 NOTE: On DECstation 3100 Ultrix, there is a bug in fork() which causes the monitor to hang on its first invocation. To get around this problem, start the monitor, type "\g " from the monitor prompt, wait a few seconds, kill the monitor with C, and start it again. It will work after this. d883 2 a884 1 backend \- used by createdb to create system relations d886 1 @ 1.12 log @Version 2.03 Upgrade. @ text @d47 1 a47 1 C-Only Release 2.03 d346 1 a346 1 The file "postgres-v2r03.tar.Z" will appear in your \*(PG home directory. d359 1 a359 1 postgres-v2r03.tar.Z d363 1 a363 1 % uncompres postgres-v2r03.tar.Z d368 1 a368 1 postgres-v2r03.tar d373 1 a373 1 % tar xvf postgres-v2r03.tar d626 1 d628 1 d633 3 a635 1 will be generated. d673 1 a673 1 $Revision: 1.11 $ $Date: 90/11/01 17:00:14 $ @ 1.11 log @We don't support Ultrix 4.0. @ text @d47 1 a47 1 C-Only Release 2.01 d136 5 a140 5 supported on DECstations running Ultrix LOWER than 4.0. Unsupported ports for DECstation Ultrix 4.0 and Sequent Symmetry machines running Dynix are included. These ports are unsupported for the following reasons: we are having various problems porting to Ultrix 4.0 but Postgres mostly works (see the release notes), and the standard d346 1 a346 1 The file "postgres-v2r01.tar.Z" will appear in your \*(PG home directory. d359 1 a359 1 postgres-v2r01.tar.Z d363 1 a363 1 % uncompres postgres-v2r01.tar.Z d368 1 a368 1 postgres-v2r01.tar d373 1 a373 1 % tar xvf postgres-v2r01.tar d503 1 a503 1 In order to reconfigure your DECstation 3100 Ultrix kernel, d669 1 a669 1 $Revision: 1.10 $ $Date: 90/10/28 13:57:01 $ @ 1.10 log @Added disclaimer for DECstations. @ text @d134 7 a140 7 processors with SunOS 3.4, or 3.5, and 4.0, Sparc architecture machines (Sparcstation and Sun 4) running SunOS 4.0 and higher, as well as Digital Equipment Corporation DECstation 3100 computers running Ultrix 4.0. An unsupported port for DECstations running Ultrix lower than 4.0 is included, as well as an unsupported port for Sequent Symmetry running Dynix. These ports are unsupported for the following reasons: the dynamic loading mechanism on Ultrix less than 4.0 is severely limited, and the standard d143 1 a143 2 Sequent Symmetry cannot compile Postgres. Other than these disclaimers, these two ports work as well as the others. d669 1 a669 1 $Revision: 1.9 $ $Date: 90/10/28 13:54:37 $ @ 1.9 log @*** empty log message *** @ text @d670 1 a670 1 $Revision: 1.8 $ $Date: 90/10/27 20:10:59 $ d795 5 a799 4 NOTE: On Ultrix, there is a bug in fork() which causes the monitor to hang on its first invocation. To get around this problem on DECstations, start the monitor, type "\g " from the monitor prompt, wait a few seconds, and start it again. It will work after this. @ 1.8 log @Yet more cosmetic changes. @ text @d670 1 a670 1 $Revision: 1.7 $ $Date: 90/10/27 19:57:35 $ d795 4 @ 1.7 log @Fixed some numbers @ text @d595 4 a598 3 in Step 2. You will also be asked for the name of the object tree directory. This step will take at least an hour and may take several hours on diskless Sun 3's. d670 1 a670 1 $Revision: 1.6 $ $Date: 90/10/27 19:52:29 $ a876 4 .\ .\ Keep the below indentation - this comes out correctly. .\ .\ d898 1 a898 1 The file ~postgres/O/libpq.a is created when you @ 1.6 log @More cosmetic changes. @ text @d669 1 a669 1 $Revision: 1.5 $ $Date: 90/10/27 19:48:23 $ d953 1 a953 1 These directories take up about 1 Mbyte, and can be reduced to about @ 1.5 log @Made some cosmetic fixes. @ text @d592 2 a593 1 .i Make install d669 1 a669 1 $Revision: 1.4 $ $Date: 90/10/27 18:52:01 $ a946 1 \*(PG distribution is extracted from tape: @ 1.4 log @Lots of changes for Version 2.01 @ text @d140 3 a142 1 on Ultrix less than 4.0 is severely limited, and the standard "make" on the d158 3 a160 1 a System V Release 3 compatible "make". Consult your Sequent representative a240 2 .ip \0\0\0\(bu Cleanup a388 1 Proceed now to the Configuration section. d506 1 a506 2 (your kernel config file) and /usr/sys/conf/param.c (your kernel parameters file). d551 1 d555 1 d571 6 a576 6 dec \- DS3100 running Ultrix LOWER than 4.0 ultrix4 \- DS3100 running Ultrix 4.0 sun \- Sun 3 running SunOS 3.4 or 3.5 sunos4 \- Sun 3 running SunOS 4.0 seq \- Sequent Symmetry running Dynix sparc \- Sparcstation or Sun 4 d592 5 a596 4 Make install will ask you for the port you wish to use. Use the same port as in Step 2. You will also be asked for the name of the object tree; go ahead and use the default if there is no problem. This step will take at least an hour and may take several hours on diskless Sun 3's. d611 4 a614 1 (which can be ignored) when compiling the output of YACC and LEX. d634 3 a636 1 This can be done by running createdb with the username as the first argument. d668 1 a668 1 $Revision: 1.3 $ $Date: 90/10/27 17:31:26 $ d787 7 a793 7 .ft I 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 postgres users. We terminate the query with a \eg \*- the ``go'' command to the terminal monitor. .ft R d835 1 d837 1 d840 1 a840 1 Bye d875 4 d881 1 a881 1 createdb \- creates new postgres databases d883 2 a884 2 ipcclean \- frees up garbage shared memory from failed backends vacuumd \- vacuum cleaner daemon d911 1 a911 1 # \fBcp ~postgres/O/libpq.a /usr/lib\fR d1041 5 a1045 3 .q "post_questions@@postgres.Berkeley.EDU" and via UUCP as .q "ucbvax!postgres!post_questions" . d1054 5 a1058 2 .q postgres-request@@postgres.berkeley.edu with "Add" as the subject. d1061 3 a1063 1 .q postgres@@postgres.berkeley.edu @ 1.3 log @Some other fixes @ text @d135 1 a135 1 (Sparcstation and Sun 4) running SunOS 4.1 and higher, as well as Digital d137 6 a142 4 unsupported port for Ultrix 2.7 is included, and Postgres does run on SunOS 4.0.X on Sparcs, but the dynamic loading feature needed for ADT's is unsupported under this system configuration. An unsupported port for Sequent Symmetry running Dynix is also included. d145 1 a145 1 and you will require at least 25 megabytes of disk space d209 1 a209 1 \*(PG requires 25 megabytes of disk space, d257 1 a257 1 at least 25 megabytes of free space available for \*(PG. d332 1 a332 1 if you are loading from an FTP tar file, skip to the d356 1 a356 1 the purpose of this discussion, the \*(PG tar file will be called d374 1 a374 1 Large numbers of file names and such should appear on the screen. a382 1 a393 2 .sh 3 "Kernel reconfiguration for Suns and Sparcs" .pp d406 2 a407 4 If you try to run a postgres backend process on a machine without enough shared memory, the backend will abort with an error message. d409 14 a422 2 In order to reconfigure your kernel, you will have to become root a424 17 A copy of the lines listed below can be found in the files ~postgres/misc/config.add and ~postgres/misc/param.add\** .(f \** This document assumes that you are running under a BSD environment using the C shell. In the C shell ~postgres is the home directory of the user \*(lqpostgres\*(rq. If you are using the Bourne shell, then substitute $HOME for occurrences of ~postgres and .q $ for the .q % shell prompt. .)f respectively. d451 1 a451 2 at the same time. Either of the lines will result in a kernel that a499 10 This is by far the most complicated part of the installation so these steps should be performed by someone experienced. Again, we advise you to consult the system administration section of your SunOS manual before doing this step. .pp For a brief discussion of shared memory, you may want to consult the section 2 man pages for \fIshmget()\fR, \fIshmop()\fR, \fIshmctl()\fR, etc. d503 4 a506 21 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 DEC system administration manual carefully. This task requires superuser authority and should probably not be done without the assistance of your system admistrator. We assume that whoever undergoes this procedure has an understanding of the process and procedures involved. .pp \*(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 postgres backend process on a machine without enough shared memory, the backend will abort with an error message. .pp In order to reconfigure your 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). d516 4 a519 14 After adding these lines, run config over the config file, install the new kernel, and reboot. This is by far the most complicated part of the installation so these steps should be performed by someone experienced. Again, we advise you to consult the system administration section of your DEC manual before doing this step. .pp For a brief discussion of shared memory, you may want to consult the Man pages for \fIshmget()\fR, \fIshmop()\fR, \fIshmctl()\fR, etc. d521 1 a521 1 .sh 3 "Kernel reconfiguration for Sequent Symmetrys" a522 17 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 DYNIX system administration manual carefully. This task requires superuser authority and should probably not be done without the assistance of your system admistrator. We assume that whoever undergoes this procedure has an understanding of the process and procedures involved. .pp \*(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 postgres backend process on a machine without enough shared memory, the backend will abort with an error message. .pp a536 10 This is by far the most complicated part of the installation so these steps should be performed by someone experienced. Again, we advise you to consult the system administration section of your DYNIX manual before doing this step. .pp For a brief discussion of shared memory, you may want to consult the Man pages for \fIshmget()\fR, \fIshmop()\fR, \fIshmctl()\fR, etc. d545 5 a549 11 If you did not unpack the source in /usr/postgres, and you have not created a symbolic link from /usr/postgres to the directory that .i does contain the code, you will have to edit the configuration file. Also, if you have a floating-point coprocessor on your machine, you should set the \-f68881 flag for the Sun C compiler. This is not necessary, but will substantially improve the performance of the system. d551 8 a558 1 To do this, a559 4 .i Change to the configuration directory in the directory that contains the unpacked system. .r d561 1 a561 1 % \fBcd newconf\fP d563 2 a564 14 .i Now make the new port directories and create the config.mk appropriate for this machine. .r % \fBnewport\fP When running .i newport you will be asked which distribution you are installing. For a DS3100 installation running Ultrix LOWER than 4.0, type "dec", for a DS3100 installation on Ultrix 4.0 type "ultrix4", for a Sun 3 installation running SunOS 3.4 or 3.5, type "sun", for a Sun 3 installation running SunOS 4.0, type "sunos4", for a Sequent Symmetry installation type "seq", for a Sparcstation type "sparc", and for a d566 9 a574 7 .sp 0.5v .i Now make the necessary changed to config.mk. The file newconf/README explains what the various entries in config.mk mean. .r .sp 0.5v % \fBvi config.mk\fP a575 4 .pp Look in the README file, and in config.mk, for instructions on what to change. d579 1 a579 1 GCFLAGS variable. d581 3 a583 20 By default, \*(PG will be compiled without the \-g flag for source-level debugging. The system is large, and using \-g is very expensive. If you intend to do debugging, you should change GCFLAGS in config.mk to \-g. We do not recommend doing this for casual users. Without \-g, the \*(PG tree consumes about 20 Mbytes of disk space. With \-g, the number doubles. NOTE: Do not compile Postgres with the optimizer level higher than 0 on Sparcstations running SunOS 4.1; due to an kernel bug Postgres compiled this way will CRASH YOUR SYSTEM. .sh 2 "Step 3 - Compiling \*(PG" .sh 3 "Compiling" .pp Once you have configured \*(PG, you can perform a complete compilation with the following sequence of commands: d586 1 a586 1 % \fB./Make everything\fR d590 4 a593 6 To install the code, run .(l % \fB./Make install\fR .)l in the same directory. d660 1 a660 1 $Revision: 1.2 $ $Date: 90/07/30 17:07:18 $ a898 20 .sh 2 "Performance Tuning" .pp Initial performance tuning can be achieved by tuning various system parameters. The file ~postgres/doc/bufmgr.doc describes the parameters that can be used to change the buffer pool size to tune buffer manager performance. The parameter NDBUFS, the number of buffers, is in the file ~postgres/src/storage/buffer/internal.h. Meanwhile, the file ~postgres/src/lib/H/sinvaladt.h contains parameters to tune the invalidation cache. The file plparm.h contains parameters to tune the lock manager. The appropriate paramater to tune are NMAXSEM, the maximum number of semaphores to be handled, NMAXXIDHASH, the maximum number of transactions that can be run in parallel, and NMAXLTABLE, the number of tables handled by the lock manager. d919 5 d925 1 a925 1 O/ compiled \*(PG object files d929 3 a931 1 Several additional directories are also created as the d939 2 a940 11 If space is limited on your system, you can delete these additional directories. Additionally, if you do not wish to use \*(PG for development, you can delete the following directories \fIafter compiling and testing is done\fR: .(l O/ compiled \*(PG object files and libraries src/ \*(PG source files newconf/ make utilities .)l @ 1.2 log @various changes. @ text @d47 1 a47 1 C-Only Release 2.0 d134 7 a140 5 processors with SunOS 3.4 or 3.5, as well as Digital Equipment Corporation DECstation 3100 computers running Ultrix 2.0 Rev 7. Ports for Sparcstation 1, SunOS 4.0 on Sun 3's, and Sequent Symmetry minicomputers are also included in the distribution. d153 3 a155 2 A Sequent Symmetry port is available, except that you will have to obtain a System V Release 3 compatible "make" in order to compile \*(PG. d255 2 a256 2 at least 20 megabytes of free space available for \*(PG. If you haven't any single partition with 20 megabytes free, d343 1 a343 1 The file "postgres-v2r0.tar.Z" will appear in your \*(PG home directory. d356 1 a356 1 postgres-v2r0.tar.Z d360 1 a360 1 % uncompres postgres-v2r0.tar.Z d365 1 a365 1 postgres-v2r0.tar d370 1 a370 1 % tar xvf postgres-v2r0.tar d647 3 a649 2 For a DEC installation, type "dec", for a Sun 3 installation running SunOS 3.4 or 3.5, type "sun", d651 2 a652 2 type "sunos4", for a Sequent Symmetry installation type "seq", and for a Sparcstation type "sparc". d682 3 a684 1 the number doubles. d716 2 a717 1 You should see no errors during this phase. d728 1 a728 1 % ~postgres/bin/createdb \-v off postgres\fR d769 1 a769 1 $Revision: 1.1 $ $Date: 90/07/30 13:24:20 $ a868 1 number you use for \fIport\fR. d876 1 a876 1 % \fB~postgres/bin/monitor database\fR d962 2 a963 1 and corrupt databases. d967 1 a967 1 Not that the program called "backend" is not really the backend; it is d976 1 a976 1 createdb \- creates new postgres databases d978 4 a981 2 ipcclean \- frees up garbage shared memory vacuumd \- vacuum cleaner daemon @ 1.1 log @Initial revision @ text @d138 1 a138 2 distribution, although these have not been completely tested due to inaccessability. d637 15 a665 2 If you have a floating-point coprocessor, use \-f68881. d676 1 a676 1 the \*(PG tree consumes about 25 Mbytes of disk space. a686 1 % \fB./newport (see below)\fR a689 10 When running .i newport you will be asked which distribution you are installing. For a DEC installation, type "dec", for a Sun 3 installation running SunOS 3.4 or 3.5, type "sun", for a Sun 3 installation running SunOS 4.0, type "sunos4", for a Sequent Symmetry installation type "seq", and for a Sparcstation type "sparc". Also, use the default object directory name for the object tree. d720 1 a720 1 % \fsetenv POSTGRESHOME ~postgres d762 1 a762 1 $Revision: 2.0 $ $Date: 90/07/12 15:15:50 $ d895 31 a925 31 ----------------------------- | usename | usesysid | ----------------------------- | postgres | 6 | ----------------------------- | mike | 799 | ----------------------------- | sp | 1511 | ----------------------------- | jhingran | 943 | ----------------------------- | cimarron | 2359 | ----------------------------- | goh | 1994 | ----------------------------- | ong | 2802 | ----------------------------- | hong | 2469 | ----------------------------- | mao | 1806 | ----------------------------- | margo | 2697 | ----------------------------- | sullivan | 1517 | ----------------------------- | kemnitz | 3491 | ----------------------------- | choi | 3898 | ----------------------------- | plai | 3665 | ----------------------------- @