Skip site navigation (1) Skip section navigation (2)

Re: Testing needed for recent tablespace hacking

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,<pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: Testing needed for recent tablespace hacking
Date: 2004-08-31 17:34:04
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCE4569DA@algol.sollentuna.se (view raw or flat)
Thread:
Lists: 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

Responses

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2004-08-31 17:42:03
Subject: Re: Testing needed for recent tablespace hacking
Previous:From: Bruce MomjianDate: 2004-08-31 11:31:36
Subject: Re: [pgsql-hackers-win32] Testing needed for recent tablespace

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group