Re: serverless postgresql

From: Jonathan Bartlett <johnnyb(at)eskimo(dot)com>
To: Rick Gigger <rick(at)alpinenetworking(dot)com>
Cc: Jeff Bowden <jlb(at)houseofdistraction(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: serverless postgresql
Date: 2004-01-14 21:07:10
Message-ID: Pine.GSU.4.44.0401141257070.6917-100000@eskimo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

I have a different idea. I've been thinking about coding it, but haven't
had the time. This could be done with no changes to Postgres itself.

Basically, you would have a library which exported functions such as

pg_instance *pg_start(char *directory);
pg_get_connection(pg_instance *);
pg_stop(pg_instance *);
pg_initdb(char *directory)

pg_start would do the following:
1) check "directory" for an instance of the UNIX socket.
if it is there, make a Postgres connection
if it is not there, start the Postmaster server with "-k directory
-D directory/data" and then make a Postgres connection
2) Create a struct to contain the directory and any other data item we
need to connect to the database
3) Return this structure

pg_get_connection would just be a wrapper for pq_connect()

pg_stop would kill the database.

pg_initdb would simply run initdb

Does anyone see a reason why this wouldn't work?

Jon

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message lnd 2004-01-14 21:07:39 FW: Postgres: VACUUM
Previous Message Joshua D. Drake 2004-01-14 20:59:41 Re: Postgres: VACUUM