Re: serverless postgresql - Mailing list pgsql-general

From Rick Gigger
Subject Re: serverless postgresql
Date
Msg-id 007401c3dac8$a75a6760$0700a8c0@trogdor
Whole thread Raw
In response to serverless postgresql  (Jeff Bowden <jlb@houseofdistraction.com>)
Responses Re: serverless postgresql  (Doug McNaught <doug@mcnaught.org>)
Re: serverless postgresql  (Jonathan Bartlett <johnnyb@eskimo.com>)
List pgsql-general
> Jeff Bowden <jlb@houseofdistraction.com> writes:
> > That makes sense to me.  I wonder if sqlite suffers for this problem
> > (e.g. app crashing and corrupting the database).
>
> Likely.  I can tell you that Ann Harrison once told me she made a decent
> amount of money as a consultant fixing broken Interbase/Firebird
> database files.  It would be hard to make a living in the same game for
> Postgres.  Now I don't think that Firebird is any buggier than Postgres.
> But it comes in an embedded-library form; I'll bet lunch that most of
> those data corruption problems were actually induced by crashes of
> surrounding applications.

I remember reading about how some the original commerical code from
Interbase came with some bugs that corrupted databases and that those bugs
were eventually fixed in Firebird.  Don't know if that's related to this but
it could be.

Anyway since postgres uses WAL files to verify the integrity of the database
couldn't it more or less make the same guarantee's in an embedded version?
As long as the app uses the db libs unmodified and doesn't mess with the
files it creates how does simply making it embedded increase the change of
db errors resulting in database corruption?

In addition there are times when you want the ease of a relational database
but you don't need say the same level of reliability that you would on your
server.  In these cases it would be nice to just have something that is easy
to drop into your app and have it just work.  That being said I think that
in these cases the developer isn't usually going to care if it runs in
process or not.  Maybe a good solution would be to make a postgres library
that could be included in process that would interface with the application.
All it would do is manager spawning the real postgres process.  Then you
would have the reliability of a real server but the ease of use of an
embedded database.  Couldn't that end up being pretty transparent to the
developer?  If it was made to be easy postgres could become very popular as
an "embedded" db solution but still not have it's reputation diluted by
rampant database corruption from the application.


pgsql-general by date:

Previous
From: vhikida@inreach.com
Date:
Subject: Re: How are NULLS stored on disk for PG 7.4?
Next
From: Doug McNaught
Date:
Subject: Re: serverless postgresql