head     1.5;
branch   ;
access   ;
symbols  ;
locks    ; strict;
comment  @@;


1.5
date     91.03.07.03.45.18;  author kemnitz;  state Exp;
branches ;
next     1.4;

1.4
date     91.01.15.18.00.43;  author kemnitz;  state Exp;
branches ;
next     1.3;

1.3
date     90.10.28.14.02.18;  author kemnitz;  state Exp;
branches ;
next     1.2;

1.2
date     90.10.24.01.34.53;  author kemnitz;  state Exp;
branches ;
next     1.1;

1.1
date     90.07.30.13.41.51;  author kemnitz;  state Exp;
branches ;
next     ;


desc
@Release notes
@


1.5
log
@Updates for 2.1
@
text
@Introduction

These notes describe the known bugs, anomalies, and machine-dependencies
in the current POSTGRES release.

Copyright

The copyright for the 2.1 release of the POSTGRES DBMS is as follows.

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.

Organization

The rest of these notes are organized into three parts:

Bugs, Machine Assumptions and Port Notes, and 2.1 Upgrades over 2.03

I.  Bugs

Compiling:

Postgres cannot compile on our Sequent using the standard 'make' or the
make provided in /usr/att/bin.  If you encounter problems with the 'make'
on your Sequent, please contact your Sequent technical support contact for
further instructions.  It should compile without problems on all other
supported platforms.  Users are welcome to try GCC (with the -traditional
option) but we have never gotten it to correctly compile Postgres.

The Terminal Monitor and Postmaster:

The Terminal Monitor can only run one query at a time.  If multiple queries
are executed with one Go command (\g), unpredictable behavior will result,
although in general either the first query will execute or a parser error will
occur.

If you start up two postmaster's on the same machine using the same port,
bizarre behavior may result.

Security Hole Bug:

Postgres does not check to make sure that a user has permission to delete tuples
out of system classes.  This means that anyone can delete anyone else's
database instance out of pg_database, for example, or can delete built-in types.
So users should be careful to avoid such things, and Postgres should not be
used for secure applications.

The Rewrite Rule System:

The Query Rewrite Rule System, and functions dependent on it, is known to have
bugs.  These will be addressed in the next release - until that time, it is
suggested that the following commands be avoided:

o  Define View
o  Define Version
o  Define Rewrite Rule
o  Define POSTQUEL procedure

However, the Instance-level Rule System works well.

II.  Postgres Machine and OS Assumptions

Postgres requires the following to be present on a system:

1.  A truly compatible System V.3 'make'.  We have found that many vendors claim
    compatibility in this regard, but their make's cannot compile Postgres.

2.  A Unix 4.2 BSD kernel with System V shared memory extensions, or a System
    V kernel with 4.2BSD extensions for sockets and various CLIB functions.

3.  The C shell and Bourne shell for various installation and 'make' scripts.

4.  For the dynamic loader, a Sun or COFF compatible A.OUT format is best.

Postgres Machine Assumptions:

Postgres assumes that

sizeof(char) = 1
sizeof(short) = 2
sizeof(long) = 4
sizeof(char *) = 4

In the very least, Postgres assumes:

sizeof(char) < sizeof(short) <= sizeof(char *) <= sizeof(long) 

If problems are encountered with alignment and such in doing ports, it may be
because these assumptions are not true on the target platform.  If this is
true, some parts of the access method code may have to be rewritten.

If the above assumptions are true, porting Postgres should be straightforward,
except for the dynamic loader.

III.  Differences between 2.1 and 2.03:

Much internal code has been rewritten, largely in access methods, caching
and buffer management, and other low-level routines.

Visible Changes from 2.03:

o  The "rtree" access method now works.  

o  Btree indices can now be defined on arbitrarily long fields. 

IV. On Ports:

    Support for the following have been DISCONTINUED:

    1.  Ultrix on DECstations below 4.0      (We do support Ultrix 4.0 and up)

    We have discontinued support for these due to OS bugs which were fixed in
    later releases of these operating systems.  These OS bugs primarily
    affect the dynamic loader.  The DECstation Ultrix port for systems below
    4.0 will continue to be distributed, but it is now unsupported.

	Support for the following will be DISCONTINUED SOON:

    1.  SunOS on Sun 3's less than 4.0.

More on the dynamic loader:

1.  Make sure files you are loading do not reference symbols (either variables
    or functions) in each other.  If you do this, it will work, but you cannot
    re-load files once they are loaded.  Doing this will have unpredictable
    results.

Diskless Machines:

We have successfully ran Postgres on diskless Sparcstations, but diskless
Sun 3's have occasionally posed problems.  We have never run diskless on
DECstations or on Sequents.
@


1.4
log
@Version 2.03 Upgrade
@
text
@d8 1
a8 6
The copyright for the 2.03 release of the POSTGRES DBMS is as follows.
However, we request that this version of the POSTGRES system not be distributed
beyond your site to avoid possible negative publicity which might arise from
performance problems in this release.  We intend to fix the bugs which you
report and to add more functionally to the system before distributing
POSTGRES more widely.
d32 1
a32 1
Bugs, Machine Assumptions and Port Notes, and 2.03 Upgrades over 2.0
a51 14
If the Postgres process invoked by the Terminal Monitor crashes, the Terminal
Monitor itself will print the following cryptic message:

"Unexpected Identifier: ? - Trying to Re-establish Communication".

If this occurs, the Postmaster should be killed and restarted as it is highly
possible that shared memory is corrupted and other Postgres processes may be
affected.

In the DECstation version, an ULTRIX fork() bug causes the monitor to
hang the first time it is run with a postmaster.  Type \g and wait for five
seconds and then kill the monitor with control-C.  Then start up the monitor
again and everything should work fine.

d55 1
a55 1
Security Holes:
d58 2
a59 2
out of system relations.  This means that anyone can delete anyone else's
database tuple out of pg_database, for example, or can delete built-in types.
d63 1
a63 1
II.  Postgres Machine and OS Assumptions and Port Notes:
d65 13
d105 1
a105 1
true, access method code may have to be rewritten.
d110 1
a110 1
III.  Differences between 2.03 and 2.0:
d112 2
a113 1
Visible Changes from 2.0:
d115 1
a115 7
B.  A reworked dynamic loading scheme.  The Postgres dynamic loading scheme
    has been completely reworked, and now works on all ports.  A new query
    
    load "<filename>"
    
    has been added so that loading can be done without slowing down user
    queries.
d117 1
a117 1
	BUG:  If the "load" command fails to load, Postgres should be restarted.
d119 1
a119 1
On Ports:
d121 2
d130 1
a130 1
	4.0 will continue to be distributed, but it is now unsupported.
d134 1
a134 1
	1.  SunOS on Sun 3's less than 4.0.
a147 1

@


1.3
log
@Added note about bugginess of query rewrite system.
@
text
@d8 1
a8 1
The copyright for the 2.01 release of the POSTGRES DBMS is as follows.
d37 1
a37 1
Bugs, Machine Assumptions and Port Notes, and 2.01 Upgrades over 2.0
a73 11
The Query Rewrite system:

Commands related to the Query Rewrite system are quite buggy.  This will be
fixed by 2.02 which will be out by the end of the year.  Affected commands
are as follows:

Define Postquel Function
Define Rewrite Rule
Define View
retrieve (x.y.z)

d116 1
a116 1
III.  Differences between 2.01 and 2.0:
d128 2
a131 4
A.  The Sparcstation port is now fully operational, including a dynamic loader.

Other Port Notes:

d138 6
a143 1
    affect the dynamic loader.
@


1.2
log
@First cut, 2.01 release notes
@
text
@d74 11
a130 5
A.  Query Rewrite Rule System.  The Query Rewrite rule system has been greatly
    enhanced, and numerous bugs that were present in the old system have been
    fixed.  Postquel functions are also available and work much better than
    they did in 2.0.

a147 1
    2.  SunOS 4.0.X on Sparcstations/Sun 4's (We do support SunOS 4.1 and up)
a148 3
    (We still support all SunOS on DISKFUL Sun 3's.  Diskless Sun 3's are
     a problem)

d165 1
@


1.1
log
@Initial revision
@
text
@d8 1
a8 1
The copyright for the 2.0 release of the POSTGRES DBMS is as follows.
d37 1
a37 1
Bugs, Machine Assumptions and Port Notes, and 2.0 Upgrades over 1.3 
d47 2
a48 1
supported platforms.  GCC does not work with Postgres.
a73 13
Time Range Anomalies:

Time range queries have no notion of time zones other than GMT.  Therefore,
time range queries have to be expressed in terms of GMT.

Timing and OID's:

Postgres uses the creation time to generate OID's, but Unix provides time
granularity only on the level of second intervals.  Therefore, given that
Postgres is now far faster than it once was, Postgres now encounters the
problem that is possible that two tuples in the same relation will have the
same OID.  This behavior is obviously wrong, and will be fixed in 2.1.

a81 55
The Dynamic Loader:

The dynamic loader shipped with Postgres is quite bad and is known to have
problems with the following:

1.  on DECstations, it has problems with string constants.  Instead of
    doing 

char *c = "hello"

you will have to do 

char c[6];

c[0] = 'h'; c[1] = 'e'; c[2] = c[3] = 'l'; c[4] = 'o'; c[5] = '\0';

Alternatively, reading strings out of a file will work as well.  You cannot
use "stdin" and "stdout" from stdio.h - all I/O has to be done using read,
gets, write, puts, etc. which do not use special symbols from stdio.h.

2.  It has problems with floating point numbers on all platforms.  Compiling
    with -G 0 will sometimes fix this problem, but not always.

3.  There is NO Sparcstation dynamic loader.  It has come to our attention
    that there is a built-in dynamic loader in SunOS 4.1, but we have been
    unable to acquire this version of the OS in time for this release.
    Persons using a Sparcstation should either implement a dynamic loader
    in ./src/port/sparc/dynloader.c or consult the tutorial "Adding a Built-In
    Function and Type".

Anyone who can recode the dynamic loaders so that they work properly is
encouraged (begged!) to do so, and it will be included in the next Postgres
distribution.  Unfortunately, the whole dynamic loading scheme used in
the postgres dynamic loader is inherently flawed, so we would not mind too much
if it was discarded entirely as long as the function call interface to
dynloader() is the same.  Dynamic loading is a task requiring large amounts of
time, documentation, and patience to do right, and is rather uninteresting
from a research point of view, and we simply do not have the manpower to do it
well at this time.

Hardware vendors in particular are encouraged to help us in developing effective
and bug-free dynamic loaders, as Postgres is the only publicly available fully
functional DBMS for many platforms.

4.  The following POSTQUEL commands expect dynamic loading to work:

1.  Define C function
2.  Define Type
3.  Define Operator

An alternative to dynamic loading is to add the function directly to the
list of Postgres builtins.  See the tutorial "Adding a Builtin Function and
Type" for details.  If this is done, Define Type and Define Operator can be
used even without dynamic loading.

d94 2
d105 4
d116 1
a116 1
III.  Differences between 2.0 and 1.3:
d118 1
a118 1
Visible Changes from 1.3:
d120 4
a123 4
A.  Rule System.  The Postgres rule system has been changed in terms of both
    functionality and syntax.  See the Reference Manual under "Define Rule"
    for details, as well as the paper "On Rules, Procedures, Caching, and
    Views" which is included in this distribution.
d125 7
a131 1
Internal changes:
d133 1
a133 6
A.  Hybrid hashjoin.  The hybrid hashjoin scheme of doing joins has been
    implemented in Postgres, and is used for equality joins.  Currently, we
    handle partition overflow in a simplistic way, by growing the hash table
    in virtual memory, which is limited by swap space.   However, partition
    overflow rarely happens.  Recursive hash partitioning will be implemented
    in Postgres 2.1.
d135 1
a135 3
B.  Transaction system.  The Postgres transaction system has been rewritten,
    so it is now much faster and appears to lack the bugs which were present
    in the old transaction system.
d137 1
a137 1
New functionality:
d139 1
a139 3
A.  Arrays.  Tuples can now have array attributes.  Arrays can be fixed or
    variable length sequences of fixed length elements.  Please consult the
    tutorial "Defining an Array Type" for details about the use of arrays.
d141 2
a142 5
B.  C functions of a tuple, also known as inheritable functions.  C functions
    can now process arbitrary attributes from a given tuple as well as
    processing attribute arguments passed via the query language.  The new
    function "GetAttribute()" is used to do this.  Please consult the tutorial
    "Writing a Function of a Tuple" for details.
d144 2
a145 4
C.  Postquel functions.  Postgres now supports a simple form of a Postquel
    function.  A more fully functional version of this command will be
    implemented in 2.1.  Please consult the Reference Manual under "Define
    Postquel Function" for details.
d147 3
a149 1
New Ports:
d151 1
a151 3
A.  Sparcstation port.  Aside from functionality which requires use of
    dynamic loading (which unfortunately includes much of the demo), Postgres
    is fully functional on Sparcstations and Sun 4 machines.
d153 10
a162 4
B.  Supported SunOS 4.0 port.  Postgres is now supported (not just distributed)
    on SunOS 4.0.  However, Postgres 1.3 did not work on diskless SunOS 4.0
    machines, and it is unknown whether 2.0 will as we have no such machines
    in house.
@