Re: [mail] Re: Windows Build System
От | Tom Lane |
---|---|
Тема | Re: [mail] Re: Windows Build System |
Дата | |
Msg-id | 19748.1043942184@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [mail] Re: Windows Build System (Hannu Krosing <hannu@tm.ee>) |
Ответы |
Re: [mail] Re: Windows Build System
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: