Re: Copy_from gets stuck with bigger input file

2008/5/27 Federico Di Gregorio <[email protected]>:
> I just commited to the trunk a change that allows psycopg to raise an
> error instead of locking when there is an error during the COPY
> operation. There is definitely something bad going on here:
>
> The call to PQputCopyData() returns -1 (error) and calling
> PQerrorMessage prints the following error:
>
> server closed the connection unexpectedly
>        This probably means the server terminated abnormally
>        before or while processing the request.
>
> Uh?! Anyway that explains why any successive send operation fails and
> trying to get something from the server just hangs forever. The problem
> is that PQstatus() returns CONNECTION_OK and PQtransactionStatus()
> returns PQTRANS_ACTIVE, so there is no way to cleanup cleanly. So the
> fix is to simply mark any connection that fails in COPY as
> "bad" (closed) forcing the client code to cope with the exception and
> re-open it.
>
> Someone with more time than me should really write to PostgreSQL devel
> mailing list asking:
>
>     1. Why if the server says "server closed the connection
>        unexpectedly" the connection is not marked as CONNECTION_BAD?
>     2. Why the COPY fails in the first place?
>
> Comments?

I've got some code in the Storm test suite to help test disconnection
behaviour by setting up a simple TCP proxy between psycopg and
Postgres.  It might help in putting together a reproducable test for
the psycopg test suite.

The code is in tests/databases/proxy.py of the main storm branch (bzr
branch lp:storm).

James.
_______________________________________________
Psycopg mailing list
[email protected]
http://lists.initd.org/mailman/listinfo/psycopg