Hannu Krosing <hannu@tm.ee> writes:
> Kill -9 seems to me _less_ severe than yanking the plug but much easier
> to automate, so that could be the first thing to test. You have no hope
> of passing the pull-the-plug test if you can't survive even kill -9.
Actually, they're two orthogonal issues.
In the pull-the-plug case you have to worry about what is on disk at any
given instant and whether you can make all the bits on disk consistent
again. (And also about whether your filesystem can perform the
equivalent exercise for its own metadata; which is why we are
questioning Windows here. Oracle's Windows port may have an advantage,
if they bypass the OS to do raw disk I/O as they do on other platforms.)
In the kill -9 case there is no risk of losing data consistency on disk,
because the OS isn't crashing; whatever we last wrote we can expect to
read. The issue for kill -9 is whether we can deal with leftover
dynamic state, like pre-existing shared memory segments, pre-existing
SysV semaphores, TCP port numbers that the kernel won't reassign until
some timeout expires, that kind of fun stuff. The reason the TIP is
still there is that there are platforms on which that stuff doesn't work
very nicely. It's better to let the postmaster exit cleanly so that
that state gets cleaned up. I have no idea what the comparable issues
are for a native Windows port, but I bet there are some...
regards, tom lane