Re: embedded/"serverless" (Re: serverless postgresql) - Mailing list pgsql-general

> Personally, I would use something like berkelydb for an embedded database
> engine.  As a general rule, if it needs to be embedded, you don't need sql.
> I'm sure you could think of areas where you could use a full blown sql
> server, but in practice that generally isn't the case.  And like  others
> have already mentioned, if you are embedding a database in software that a
> user has control of, you want it as SIMPLE as possible.

But the user isn't the one accessing the database directly.  Have you ever
used a program like Delphi to create applications?  Using a relational
database, you can create applications using nothing but drag-and-drop and
SQL.  No real code.  If your application is a simple end-user app (like a
wedding planner, for example),  embedded databases are your dream come
true.  Linux has no real embedded database.  PG would be an excellent
embedded database.  I have already proposed some functions that would help
PG as an embedded database, and, if I hve time, I will implement them
(can't right now because I'm finishing a book).

Anyway, I get the feeling that those people who don't like the idea of
having PG as an embedded database have never used one.  I think Tom, for
example, has been focusing on enterprise-level applications too much to
think about the personal applications, and Chris, I'm going to guess
you've never built an application w/ an embedded DB.

Anyway, this thread is going nowhere, I'll come back if/when I have some
code.  Perhaps with something concrete we can all see better where this is
going.

Jon

>
> Chris
>
>
>
> ----- Original Message -----
> From: "Tom Lane" <tgl@sss.pgh.pa.us>
> To: "Rick Gigger" <rick@alpinenetworking.com>
> Cc: "Chris Travers" <chris@travelamericas.com>; "David Garamond"
> <lists@zara.6.isreserved.com>; "Jeff Bowden" <jlb@houseofdistraction.com>;
> "pgsql-general" <pgsql-general@postgresql.org>
> Sent: Friday, January 16, 2004 1:14 PM
> Subject: Re: embedded/"serverless" (Re: [GENERAL] serverless postgresql)
>
>
> > "Rick Gigger" <rick@alpinenetworking.com> writes:
> > >> ... just adds potential for mucking things up.  I can see the bug
> > >> reports now: "I decided I'd make the shutdown routine 'kill -9' the
> > >> postmaster because I didn't like the multi-second delay for a normal
> > >> shutdown.  Now my database is corrupt."
> >
> > > I recall a discussion a while back where people were complaining that
> some
> > > os (I think it was mac os x) would just kill all proccesses after
> something
> > > like 30 seconds on system shutdown if they didn't quit fast enough on
> their
> > > own.  The response was that because of how postgres uses wal files to
> > > prevent db corruption this was not an issue.  Why does this not apply in
> > > this situation?
> >
> > Because a system shutdown doesn't leave anything else running.  kill -9
> > on the postmaster leaves orphaned backends still running, and orphaned
> > shared memory segments still in existence.  The latter could prevent you
> > from starting a fresh postmaster (because two shmem segments could
> > exceed the kernel's SHMMAX) until you do manual cleanup, which most
> > people don't know how to do.  If you do succeed in starting another
> > postmaster with a fresh shared memory segment, you will have two
> > independent sets of backends modifying the database files with no
> > interlocking, which is a sure recipe for data corruption.
> >
> > There is an interlock that is supposed to prevent this catastrophic
> > scenario, but I do not trust it unreservedly (and not at all on
> > non-Unix-derived platforms, because it depends on some rather arcane
> > features of the SysV shared memory API, which might not be implemented
> > fully on other platforms).
> >
> > This is why the "don't kill -9 the postmaster" TIP is still around, BTW.
> > It has nothing to do with crash safety.
> >
> > > By saying "the client can scribble on the database anyway" do you do you
> > > mean the client app actually writing over the db files on disk?  It
> seems
> > > like this would only be a problem with an exceptionally stupid
> programmer.
> > > How could that happen on accident?
> >
> > Scribbling on memory that doesn't belong to you isn't something one does
> > intentionally, either --- but it happens.  However, my real concern here
> > is not so much with program bugs as clueless users.  We see enough cases
> > already of people removing lock files or "unnecessary" log files; I fear
> > it'd be a lot worse if those files were sitting in the user's home
> > directory.
> >
> > regards, tom lane
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>