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

Поиск
Список
Период
Сортировка
От Rick Gigger
Тема Re: embedded/"serverless" (Re: serverless postgresql)
Дата
Msg-id 001b01c3dc5c$bd9338f0$0700a8c0@trogdor
обсуждение исходный текст
Ответ на serverless postgresql  (Jeff Bowden <jlb@houseofdistraction.com>)
Ответы Re: embedded/"serverless" (Re: serverless postgresql)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Eric Ridge
Дата:
Сообщение: Re: Best Practice for incremental development
Следующее
От: Joe Conway
Дата:
Сообщение: Re: check date validity