"Rick Gigger" <rick@alpinenetworking.com> writes:
>> ... 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?
Because a system shutdown doesn't leave anything else running. kill -9
on the postmaster leaves orphaned backends still running, and orphaned
shared memory segments still in existence. The latter could prevent you
from starting a fresh postmaster (because two shmem segments could
exceed the kernel's SHMMAX) until you do manual cleanup, which most
people don't know how to do. If you do succeed in starting another
postmaster with a fresh shared memory segment, you will have two
independent sets of backends modifying the database files with no
interlocking, which is a sure recipe for data corruption.
There is an interlock that is supposed to prevent this catastrophic
scenario, but I do not trust it unreservedly (and not at all on
non-Unix-derived platforms, because it depends on some rather arcane
features of the SysV shared memory API, which might not be implemented
fully on other platforms).
This is why the "don't kill -9 the postmaster" TIP is still around, BTW.
It has nothing to do with crash safety.
> 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?
Scribbling on memory that doesn't belong to you isn't something one does
intentionally, either --- but it happens. However, my real concern here
is not so much with program bugs as clueless users. We see enough cases
already of people removing lock files or "unnecessary" log files; I fear
it'd be a lot worse if those files were sitting in the user's home
directory.
regards, tom lane
