Re: embedded/"serverless" (Re: serverless postgresql)

On Thu, Jan 22, 2004 at 01:04:29PM -0700, Rick Gigger wrote:

[PostgreSQL ill-suited to embedded use]

> How about the following comment from an earlier post:
>
> > Now, while I think that an embedded fork of PostgreSQL is completely
> > missing the point I do think that a low maintenance fork or
> > configuration option would be a very useful feature. I'd love to
> > be able to ship an application that would
> >
> > o Have a private installation of PostgreSQL
> >
> > o That would run semi-persistently - if the DB isn't running, the
> > application will transparently start it, and if the DB is idle
> > for some length of time it gracefully shuts down
> >
> > o Is zero-maintenance - all vacuuming, analysing etc is handled
> > automatically. So are database version upgrades.
> >
> > o That runs under the permissions of the user running the application
> >
> > o And that could, by tweaking an application configuration variable
> > could swap out the private PostgreSQL installation and instead
> > access a standard installation
>
> Is this something that could make sense for postgres?

It is something that could be done without touching the PostgreSQL
core code - for instance, by dropping a transparent shim in front of
libpg that maintains a little state and intercepts some of the calls
to libpg, yet presents the same API to the application.

Add a flag to the connect string to identify an attempt to connect to
a private installation (passing the top-level path so the shim can
find the binaries, database directory and socket). On a failed attempt
to connect to the private installation try and fork/exec the postmaster,
wait for it to spin up and then continue. Once connected, kill -TERM
the postmaster (so that it'll shutdown gracefully once everyone is
disconnected).

That'll provide everything needed for a private installation, optional
connection to a real installation, automatic spin-up and spin-down.

Vacuuming and analysing can be handled using the algorithms (and the code,
come to that) from pg_autovacuum.

That provides everything on my wish-list apart from automated version
upgrades with only a trivial amount of coding needed - probably no more
than a hundred lines of new code for a minimalist version.

Cheers,
Steve