| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Closes #633.
|
|
|
|
|
| |
Solaris does not have timeradd and timersub. Add solaris_support.c which
provides emulated versions of them on Solaris.
|
|
|
|
|
|
|
|
|
| |
It fails on Py3 after receiving a SIGABRT. Because we don't handle it
here it will resurface later with nonsense such as:
SystemError: <some function> returned a result with an error set
Close #551
|
|
|
|
| |
Close #410
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
From the DB-API (https://www.python.org/dev/peps/pep-0249/):
OperationalError
Exception raised for errors that are related to the database's
operation and not necessarily under the control of the programmer,
e.g. an unexpected disconnect occurs, [...]
Additionally, psycopg2 was inconsistent, at least in the async case:
depending on how the "connection closed" error was reported from the
kernel to libpq, it would sometimes raise OperationalError and
sometimes DatabaseError. Now it always raises OperationalError.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a race condition that only seems to happen over Unix-domain
sockets. Sometimes, the closed socket is reported by the kernel to
libpq like this (captured with strace):
sendto(3, "Q\0\0\0\34select pg_backend_pid()\0", 29, MSG_NOSIGNAL, NULL, 0) = 29
recvfrom(3, "E\0\0\0mSFATAL\0C57P01\0Mterminating "..., 16384, 0, NULL, NULL) = 110
recvfrom(3, 0x12d0330, 16384, 0, 0, 0) = -1 ECONNRESET (Connection reset by peer)
That is, psycopg2/libpq sees no error when sending the first query
after the connection is closed, but gets an error reading the result.
In that case, everything worked fine.
But sometimes, the error manifests like this:
sendto(3, "Q\0\0\0\34select pg_backend_pid()\0", 29, MSG_NOSIGNAL, NULL, 0) = -1 EPIPE (Broken pipe)
recvfrom(3, "E\0\0\0mSFATAL\0C57P01\0Mterminating "..., 16384, 0, NULL, NULL) = 110
recvfrom(3, "", 16274, 0, NULL, NULL) = 0
recvfrom(3, "", 16274, 0, NULL, NULL) = 0
i.e. libpq received an error when sending the query. This manifests as
a slightly different exception from a slightly different place. More
importantly, in this case connection.closed is left at 0 rather than
being set to 2, and that is the bug I'm fixing here.
Note that we see almost identical behaviour for sync and async
connections, and the fixes are the same. So I added extremely similar
test cases.
Finally, there is still a bug here: for async connections, we
sometimes raise DatabaseError (incorrect) and sometimes raise
OperationalError (correct). Will fix that next.
|
|
|
|
|
| |
MSVC doesn't like referencing new initialized variables in the variable
declaration section.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Store the state in the connection object and set the params on BEGIN
Some tests fail: a few can be fixed reading transaction_* instead of
default_transaction_*; but the behaviour of tx characteristics with
autocommit is effectively changed. It may be addressed by setting
default_transaction_* if autocommit is set.
|
|
|
|
|
|
| |
Store the encode/decode functions for the right codec in the connection.
The Python encoding name has been dropped of the connection to avoid the
temptation to use it...
|
|
|
|
| |
0 is a valid length, isn't it?
|
| |
|
|
|
|
|
|
|
|
| |
PGRES_COPY_BOTH was introduced in 9.1: we can ifdef the hell out of
pgpath, but we may as well bury the dead horses instead of beating
them.
They smell funny, too.
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
tests/testconfig.py
|
| | |
|
| |
| |
| |
| | |
Close issue #412.
|
| | |
|
|\ \
| |/ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
It makes more sense this way, because otherwise it must be passed to every call
of `read_message()`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/ |
|
| |
| |
| |
| | |
Fixes #352.
|
| |
| |
| |
| |
| |
| | |
Suggested by Craig Ringer in pull request #353, should also give more
information for other cases we were reported on flaky servers (AWS,
digital ocean...), see bug #281.
|
| |
| |
| |
| |
| |
| | |
The libpq's PQconsumeInput() returns 0 in case of an error only, but
we need to know if it was able to actually read something. Work
around this by setting an internal flag before retry.
|
| |
| |
| |
| | |
When connection is closed by the server, we might get -1 there.
|
| |
| |
| |
| | |
Only call when no data is available in the internal buffer.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change exposes lower level functions for operating the
(logical) replication protocol, while keeping the high-level
start_replication function that does all the job for you in
case of a synchronous connection.
A number of other changes and fixes are put into this commit.
|
| |
| |
| |
| | |
use LSN instead of msg reference in cursor.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Move libpq-specific code for streaming replication support into a
separate file. Also provide gettimeofday() on Win32, implementation
copied from Postgres core.
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Introduce ReplicationConnection and ReplicationCursor classes, that
incapsulate initiation of special type of PostgreSQL connection and
handling of special replication commands only available in this special
connection mode.
The handling of stream of replication data from the server is modelled
largely after the existing support for "COPY table TO file" command and
pg_recvlogical tool supplied with PostgreSQL (though, it can also be
used for physical replication.)
|
|
|
|
|
|
| |
Apparently this has never happened... anyway the code path was wrong.
Fixes #294.
|
|
|
|
| |
Fix ticket #270.
|
|
|
|
|
|
| |
Building without extensions has been long broken and nobody really cares
about a pure-DBAPI implementation (which could be created using a wrapper
instead).
|
|
|
|
|
|
| |
Also, don't start an implicit transaction when fetching with
named with hold cursor, since it already returns results
from a previously committed transaction.
|
|
|
|
| |
Close ticket #219
|