Re: Testing needed for recent tablespace hacking
От | Magnus Hagander |
---|---|
Тема | Re: Testing needed for recent tablespace hacking |
Дата | |
Msg-id | 6BCB9D8A16AC4241919521715F4D8BCE4569DA@algol.sollentuna.se обсуждение исходный текст |
Ответ на | Testing needed for recent tablespace hacking (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Testing needed for recent tablespace hacking
|
Список | pgsql-hackers-win32 |
>Would someone check that I didn't break the Windows port with this >recent commit: Took a whlie, sorry. Been away or busy for a couple of days. >I had to do some fooling around with platform-specific code, so it's >possible that things are broken. Please test that the above-mentioned >four commands still work. Also see if they work when WAL-replayed. >(The easy way to check this is to do one and then "kill -9" the backend >as soon as it completes.) One test case for the former PANIC bug is to >run the regression tests using "make installcheck", then immediately >start another backend and kill -9 it (you must do this before a >checkpoint occurs in order to exercise the bug case). I've tested this: psql to a backend in a test db, do create tablespace kill -9 (using taskman, say about 5 seconds later) psql to a backend - tablespace is there. do drop tablespace kill -9 (using taskman, say about 5 seconds later) psql to a backend - tablespace is gone create database also appears to work from what I can tell. Is that enouhg testing, or are more steps needed? >Is there any reason lstat() wouldn't work on Windows? It's #defined to stat(), which should work. It won't know anything about our symlinks, but that shouldn't matter. //Magnus
В списке pgsql-hackers-win32 по дате отправления: