Subject: X-Mn-Key: postgres

From: [email-masked] (Corey Sweeney)
Date: Tue, 9 Nov 1993 01:21:35 +0200

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
>[email-masked]

Corey Sweeney
[email-masked]

---

From: [email-masked] (Kai Petzke)
Date: Thu, 11 Nov 1993 16:16:54 +0200

Hello,

Corey Sweeney writes:

> I wrote:

Ok, lets say logging instead of locking in the future :-)

The problem is, that 1) is dependant on 2).  If you back up a running
database, you have never an consistent image of the database on your copy.
To get it consistent again, you need the information about what was modified,
while the backup was taken.

Ok, postgres supports time travel, in other words: it never deletes old
information (unless vacuum'ing the database), and any change is marked
with a timestamp.  After an restore, postgres could go through the
database and invalidate everything, which is newer than the start of the
backup.  This is not applicaple to indexes, though, they must be rebuild.

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

- tkmonitor seems to be on the Yggdrasil CD (I have not yet been able to
  take a look at it, because I bought a Philips/LMSI CD-ROM drive, one of
  the view, which is missing a Linux driver.  I am in the process of writing
  a Linux driver for it).

- Onyx, a copylefted 4gl, may become an postgres/ingres link (yesterday,
  the developper of it, Michael Kraehe, [email-masked] e-mailed
  me about this thing).

- The xpg thing shouldn't be too hard to do.

I believe, that easy-to-use frontends will greatly increase the number of
users.  Ok, it *is* overkill to use an object-oriented, multi-user rdbms
like postgres to store the telephone numbers of your friends.  But by
encouraging people to do this thing, we can spread postgres.  Once it
is part of many Linux distributions (like it is already of the Yggdrasil
CD) we will find many new users.

> 4.0.1 we might cause ourselfs trouble when we move to the next version).

At the moment, I am busy writing a CD-ROM driver.  Soon, I shall have
more time to take a look at postgres again (I will also by a new hard
disk today, increasing my disk space).  I will try to recompile 4.1 with
all optimizer options off.  Maybe, the problem with concurrent access is
just because gcc assumes, that variables stored in the shared memory don't
change ...

I wouldn't like to spend to much efforts with 4.0.1, if 4.2 may/will/shall
come out, when the ALPHA thing is finished.

> we could write a script to do this(that would have to be run as root)

The problem is 1), because everybody uses different login stuff (with or
without shadowing, etc., etc.).

Kai Petzke