Tom Lane wrote:
>"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."
>
>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.
>
>
>
Still, the main problem I, and I suspect others, would like to solve is
installation/configuration. For my app I don't want the user to have to
understand anything about how keeping data in a shared
system-administered database is different from keeping data in local
files. Everything should "just work". There is no requirement for
concurrent access.
So kill -9 on postmaster can lead to database corruption? What happens
in a power failure?
