Delivery-Date: Thu, 11 Nov 93 12:39:55 -0800
Message-Id: <199311111438.AA16596@marie.physik.tu-berlin.de>
Subject: Re: future of postgres for Linux
Sender: owner-linux-activists@joker.cs.hut.fi
To: linux-activists@joker.cs.hut.fi
Date: Thu, 11 Nov 1993 16:16:54 +0200
From: wpp@marie.physik.tu-berlin.de (Kai Petzke)
In-Reply-To: <9311082322.AA02l2v@amiganet.xnet.com>; from "Corey Sweeney" at Nov 9, 93 1:21 am
Content-Type: text
Content-Length: 4653


Hello,

Corey Sweeney writes:

> I wrote:
> 
> >- 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.

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.


> 
> (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.

- 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, kraehe@bekunin.north.de 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.

> 
> 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?

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.

> 
> >
> >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)

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

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