The Windows server version of PostgreSQL uses a function called pgkill in the
file kill.c in place of the UNIX kill function. This pgkill function
simulates some of the SIGHUP like commands by passing signals through a named
pipe. Because it is passing the signal through a pipe, the server doesn't get
the kill signal immediately and therefore fails the test on
test_connection.ConnectionTests.test_cleanup_on_badconn_close.
Ideally, the test should check to see if the server is running on Windows, not
the psycopg.
Postgres 9.3 turns messages about implicit indexes and sequences from NOTICE
to DEBUG1 so the tests fail with a default 9.3 server configuration because
the client doesn't get any NOTICE. Fix it by also asking for DEBUG1 messages
from the server when testing against Postgres >= 9.3.
Failing to do so was causing the issue reported in ticket #103. The issue
as reported was fixed when SET ISOLATION LEVEL was dropped, but the real
problem wasn't fixed.
This basically removes the READ UNCOMMITED level (that internally
PostgreSQL maps to READ COMMITED anyway) to keep the numeric values
compattible with old psycopg versions. For full details and discussion
see this thread:
http://archives.postgresql.org/psycopg/2011-12/msg00008.php
In fact it doesn't change "the transaction", as there has to be no
transaction when invoked. The effect instead is to execute SET SESSION
CHARACTERISTICS.
The encoding can be set by PGCLIENTENCODING, which may be an alternative
spelling. Bug reported by Peter Eisentraut.
At this point the idea of considering one of the random spellings such as
EUC_CN as somewhat "blessed" is debunked. So just store the cleaned-up
version of the encoding in the mapping table. Note that the cleaned-up
version was needed by the unicode adapter: this requirement has been
surpassed as the connection now contains a copy of the Python codec name
set whenever the client encoding is set.
With test_concurrent_execution test, checking two threads issuing a pg_sleep
of 2 seconds and and check if they complete in under 3 seconds occasionally
fails when the test is run in a virtual machine on a VM Server with other
virtual machines running. Increased the sleep to 4, and the check to 7,
giving 3 seconds buffer instead of 1 second.
Using self.conn.dsn as the dsn connection string actually has the password
'x'ed out. The initial connection replaces the password with 'x' to
obfuscate it. Using tests.dsn instead of self.conn.dsn ensures that the
correct connection string is used.
We don't do somersaults to ensure people can use snowmen as transaction
ids anyway: it would require passing the connection to xid_ensure and
down below to use the correct encoding.
