Drop user did not reduce size of tablespace file

The following should do it:

1. Shut down PostgreSQL
2. Make sure PostgreSQL does not run any longer
3. Check that PostgreSQL is really stopped
4. Copy the old data directory to the new drive
   This is usually defined through a commandline parameter (-D) for your service or through the PGDATA environment variable.
5. Update your PostgreSQL configuration (service, environment var) to point to the new data directory.
6. If you copied the data, rename the old data directory to make sure PostgreSQL cannot find it any longer. That way you'll get an error message if you didn't get the configuration right.
7. Start the service
8. If everything is running fine, you can delete the old directory.

If you've dropped all the tables, you could just drop the database and re-create it. It will be created with the default sizes and growth rates as defined by the model database. These may not be ideal (I don't find the defaults particularly useful in most scenarios), but you can change them.

Unless you have a lot of things set up on this database (like Service Broker, a ton of users, etc.), I think that is less cumbersome than getting into the habit of growing/shrinking growing/shrinking growing/shrinking. You should put the database on a drive that has enough space to accommodate the data you're going to generate, without having to shrink all the time. Shrinking and growing are both expensive events, especially on slow I/O.

Also, to prevent the log from growing to 9 GB (that seems pretty ridiculous for the data you describe), you should either be full recovery and you need to perform more frequent backups and log backups, or you should switch to simple recovery. More details here - it's long but please read it all.