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.
If the connection is sync, notices will be processed by pq_fetch()
downstream.
If the connection is async, here we have only sent the query: no result
is ready yet, and neither notices have had a chance to arrive: they will
be retrieved later by pq_is_busy().
Added tests to check the above statement don't break.
