At the end of Part 2, I suggested those who were anxious to start testing could try python tests\dbobject\test_schema.py right after installing psycopg2, and implied everything would work just fine by showing the output of a successful run.
That was deceptive because before running the Pyrseas tests you need to create a PostgreSQL user. So you first need to connect using psql or pgAdmin, as the postgres user and issue a command such as the following:
CREATE USER username CREATEDB SUPERUSER password;
Of course, username and password should be your user name and a suitable password, respectively. While you’re at it, you can also create the two testing roles:
CREATE ROLE user1; CREATE ROLE user2;
The user username needs the CREATEDB privilege to create the Pyrseas test database, by default, pyrseas_testdb. Alternatively, the test database could be created first, e.g., by postgres and owned by username. Also, if username isn’t granted the SUPERUSER privilege then the tests requiring it will be skipped.
One last detail before being able to run the tests: create a PostgreSQL password file, i.e., %APPDATA%\postgresql\pgpass.conf. The format is straightforward:
*:*:*:username:password
Make sure you have the latest pyrseas/testutils.py. It includes a change to make the tests portable to Windows. You’re now ready to give all the tests a whirl:
python tests\dbobject\__init_py
or you may prefer to use test discovery:
python -m unittest discover -s tests/dbobject
One of the first issues you’ll notice is when running test_tablespace.py, which exercises support for PostgreSQL tablespaces. According to the documentation, “tablespaces can be used only on systems that support symbolic links” (aside: thanks to Andres Freund and Merlin Moncure for answering questions about this on IRC).
It seems Windows Vista (or even XP) may have something akin to symbolic links (junctions?). Nevertheless for Pyrseas, it is sufficient to create directories for the tablespaces, e.g.,
C:\>md c:\somedir\pg\9.1\ts1 C:\>md c:\somedir\pg\9.1\ts2
However, when you try to define the tablespace from psql, you’ll probably see:
postgres=# CREATE TABLESPACE ts1 LOCATION E'C:\\somedir\\pg\\9.1\\ts1'; ERROR: could not set permissions on directory "C:/somedir/pg/9.1/ts1": Permission denied
The problem is that the directory needs to be owned by the postgres user. Unfortunately, there is nothing equivalent to chown on native Windows XP Home. Andres had mentioned cacls and after some web searching and trying, I came up with the following commands as the nearest approximation to chown:
cacls c:\somedir\pg\9.1\ts1 /E /G postgres:F cacls c:\somedir\pg\9.1\ts2 /E /G postgres:F
These give the postgres user FULL owner privileges over the directories. If you invoke the CREATE TABLESPACE statements again, then they should succeed … Well, at least on PostgreSQL 8.4, 9.0 and 9.1, the cacls commands allow the tablespaces to be defined. However, under 9.2 the “Permission denied” error persists (still haven’t figured out why—if you know why, do leave a comment).
Update: Thank to alemarko’s comment below, I figured out that for PG 9.2, assuming you installed with the defaults, the correct incantations to use are:
cacls c:\somedir\pg\9.2\ts1 /E /G networkservice:F cacls c:\somedir\pg\9.2\ts2 /E /G networkservice:F
Filed under: PostgreSQL, Python
