Delivery-Date: Mon, 08 Nov 93 17:53:45 -0800
Date: Tue, 9 Nov 1993 01:21:35 +0200
Message-Id: <9311082322.AA02l2v@amiganet.xnet.com>
From: corey@amiganet.xnet.com (Corey Sweeney)
Sender: owner-linux-activists@joker.cs.hut.fi
To: linux-activists@joker.cs.hut.fi
Subject: X-Mn-Key: postgres


d 3-13

>Hello,


>to whoever listens to a new created mailing list.


>Postgres is one of the most advanced database systems.  Many of its
>features are not available in normal "commercial" database systems.
>Just one example: It is able to handle abstract data types, like circles
>or points in a 2D-plane, or spheres and points in a 3D-space, or ...

>But it has a big problem:

>it is a research project, not a production system.  Postgres is designed
>to show, that certain things are possible.  Its basic goal is not to be
>a reliable and fast relational database management system.  For example,
>there are no tools to restore the database after a system crash, as far,
>as I know.  Consistent backups can not be made, while the database is
>running.

>To overcome these problems, Berkeley has licenced Postgres to a company,
>which recently brought out a product called "Miro".  They needed over
>one year to rework the code, speed up several things, and chase bugs.

>This does not mean, that Postgres is generally unstable, unreliable or
>unusable.  If your application does allow regular database shutdowns to
>be made, so that consistent backups can be made, and if you are willing
>to do work again, because a power failure trashed your database, then
>you shall be fine with postgres.

>The next problem is, that Berkeley licenses Postgres only for educational
>and non-commercial use or for research.  Every commercial user has to ask
>Berkeley for a permission.  I read somewhere, that Berkeley in general will
>grant this permission in exchange for a copy of the Postgres client, which
>they may use for educational purposes.

I own Sytron Computers,  and my company has obtained the right to
distribute and sub-licence postgres.  The contract is vague about recursive
licencing, but it appears that all changes to postgres, and programs
written with postgres must be eventually returned to berkely.

>Postgres for Linux has a few other limitations, too.  Berkeley does not
>officially support the Linux port.  And there are no "official" ports of
>any of the frontends, which are available.  (There are ports, but none of
>them have been made public, as far as I know).


>This is a bunch of problems.  I ported Postgres to Linux for fun.  It was
>too prove, that Linux is capable of "real" applications, that Linux is a
>"grown up" operating system.  It was also interest in databases, and I
>did not know Postgres before.

>Unfortunately, the "fun" part is over.  To establish postgres as a well
>working database under Linux is work.  It does include:

>- Add methods for locking all actions on the database.  On power or file
>  system failure, the database should automatically be restored.
>- Allow backups to be taken, while the database is running.
>- Improve speed.
>- Chase all bugs.
>- Port frontends.
>- Have support by many people.
>- Make installation easy and understandable.
>- Obtain a license from Berkeley, that the Postgres database system may
>  be used from any client, without further permition from Berkeley needed.
>  (That means mostly, that everything may be linked against libpq).
>


I agree with your list,  I think the priorities should be something
like the following:

1 - Allow backups to be taken, while the database is running.

2 - Add methods for locking all actions on the database.  On power or file
    system failure, the database should automatically be restored.

(those two are vital)

3 - tools to restore the database after a system crash, as far,
(added from eirlier in document)

(a database system's data security is always the top concern)
-----------

3 - Make installation easy and understandable.
(what better way to find bugs then have a lot of people reporting them :)

4 - Chase all bugs.

-----------

5 - Port frontends.

6 - Improve speed.
(I'm worried about making speed improvements.  If we make them in
4.0.1 we might cause ourselfs trouble when we move to the next version).

-----------

7 - Have support by many people.


X - Obtain a license from Berkeley, that the Postgres database system may
  be used from any client, without further permition from Berkeley needed.
  (That means mostly, that everything may be linked against libpq).

        I already got one of these (one down 7 to go:)


Should we try to get 4.1 running properly first? or do this with 4.0.1?
And does anyone have any idea when 4.2 should be comming out?


>and many more.
>
>The bug chasing is not the problem, I have already done a lot of it to get
>it working under Linux at all (and Berkeley even incorporated some of my
>changes).
>
>Porting frontends should not be the problem, either.
>
>A few people informed me, that the Picasso front end is no longer used at
>Berkeley.  They use a thing called tkmonitor, which is based on the tk/tcl
>toolkit.  The latter is available for Linux.  People e-mailed with me about
>this, even that they managed to compile and run it, and that it was no big
>problem.  Unfortunately, they did not upload it to an ftp server, at least,
>they did not tell me, that they have done so.
>
>There has another frontend been released recently, called xpg.  It is worth
>taking a look at it, too, because it uses drag-and-drop to create queries,
>etc.  It is said to need OpenWindows, which is also available for Linux.
>
>However, I do not have the RAM to run X-Windows, OpenWindows, Postgres, a
>frontend and gdb at the same time, because I am fixing a bug.  I do not
>have the hard disk space to install the source of several front ends,
>either.  I am eagerly waiting for the on-line compression file system
>for Linux.  It will make this situation much better.

Do you have live net access? would it be possible to set up a server
on the net for you to telnet into & use? (running a xclient on your
machine and everything else on the server).


>
>Nevertheless, I am willing to help with porting of any type of postgres
>related software.
>
>The biggest deal to make installation of postgres has been done by
>integrating shared memory into the standard Linux kernel.  Installation
>needs now three major steps:
>1) Creating a user named postgres (from 4.1 on, this user can have any
>   user ID and any home directory).
>2) Unpacking a binary distribution relative to postgres' home directory.
>3) Running initdb.
>
we could write a script to do this(that would have to be run as root)


>This is not the easiest way to install postgres.  Yggdrasil's new
>CD-ROM, the LGX (Linux-GNU-X-Windows) release, contains Postgres 4.1
>source and binary, as well as tkmonitor, a graphical front end.  According
>to the announcement of this CD, all installations can be done from easy
>to use menus.
>
>Corey Sweeney wants to write a guide to the postgres documentation.  It
>will make it much easier for the newbie to find the pieces of documentation,
>which they need.  In future releases of postgres, I might split the docs
>into two groups: essential and interesting, and distribute the second part
>separately.


Here is the fisrt draft of that.
*********************************

                Postgres documentaion index

                        10/15/93


To install this you want to read doc/postgres-setup.me (ASCII) or
doc/psdump/postgres-setup.ps (postscript version).

To use postgres interactivly you want to read doc/manual.me (ASCII) or
doc/psdump/manual.ps (postscript version)

To program postgres you want to read the ref/ref.ps (postscript
version).  I beileve a ascii version can be generated somehow.


Ignore the rest of the documentation, It might be interesting to read
but it wont help you get started with postgres. 

        Corey

************************************

>The biggest deal is making Postgres to automatically recover from system
>crashes.  It is something not done tomorrow.

>Kai
>wpp@marie.physik.tu-berlin.de

Corey Sweeney
corey@amiganet.chi.il.us