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

From Rick Gigger
Subject Re: embedded/"serverless" (Re: serverless postgresql)
Date
Msg-id 001b01c3dc5c$bd9338f0$0700a8c0@trogdor
Whole thread Raw
In response to serverless postgresql  (Jeff Bowden <jlb@houseofdistraction.com>)
Responses Re: embedded/"serverless" (Re: serverless postgresql)
List pgsql-general
> "Chris Travers" <chris@travelamericas.com> writes:
> > I agree with the approach of a wrapper library which would wrap the
> > startup/shutdown of a postgresql server so that the programmer doesn't
have
> > to worry about the details,
>
> The reason that the client programmer doesn't have to worry about
> starting/stopping the database is that it's not his responsibility.
> I don't think that having the client control this is a good idea at all.
> David conveniently ignored the points I made before, but they are
> real issues --- if the client is in charge of starting or stopping the
> DB, it 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?

> Another set of objections to this center around the fact that with this
> sort of arrangement, the database files would necessarily belong to the
> client user, since there's no way to launch the postmaster as a
> different userid.  (Unless the client is running as root, which I
> sincerely hope he is not.)  That means there's no filesystem protection
> between the client and the database, which is another recipe for
> trouble.  Not much point in keeping an address-space firewall between
> client and server when the client can scribble on the database anyway.

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?


pgsql-general by date:

Previous
From: Eric Ridge
Date:
Subject: Re: Best Practice for incremental development
Next
From: Joe Conway
Date:
Subject: Re: check date validity