<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/python-packages/psycopg2.git/sandbox/test_green_error.py, branch separate-binary</title>
<subtitle>github.com: psycopg/psycopg2.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/psycopg2.git/'/>
<entry>
<title>Close the connection on error in callback</title>
<updated>2012-10-09T01:01:29+00:00</updated>
<author>
<name>Daniele Varrazzo</name>
<email>daniele.varrazzo@gmail.com</email>
</author>
<published>2012-10-06T10:58:52+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/psycopg2.git/commit/?id=58d048198f88b882ce7530b5eb2dec672c36c8a0'/>
<id>58d048198f88b882ce7530b5eb2dec672c36c8a0</id>
<content type='text'>
Unfortunately PQcancel blocks, so it's not better than PQgetResult.
It has been suggested to use PQreset in non-blocking way but this would give
the Python program the burden of handling a connection done but not configured
in an unexpected place.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Unfortunately PQcancel blocks, so it's not better than PQgetResult.
It has been suggested to use PQreset in non-blocking way but this would give
the Python program the burden of handling a connection done but not configured
in an unexpected place.
</pre>
</div>
</content>
</entry>
<entry>
<title>Get the result from the connection after the green panic</title>
<updated>2012-10-09T01:01:29+00:00</updated>
<author>
<name>Daniele Varrazzo</name>
<email>daniele.varrazzo@gmail.com</email>
</author>
<published>2012-10-06T00:45:24+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/psycopg2.git/commit/?id=7632e1ae46d0f65b6302f02d0b6a5c236b84c0fe'/>
<id>7632e1ae46d0f65b6302f02d0b6a5c236b84c0fe</id>
<content type='text'>
Otherwise the connection won't be usable in case we manage
to put it back on track (libpq reports "another command is
already in progress")
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Otherwise the connection won't be usable in case we manage
to put it back on track (libpq reports "another command is
already in progress")
</pre>
</div>
</content>
</entry>
<entry>
<title>Attempt to fix issue #113.</title>
<updated>2012-10-09T01:01:29+00:00</updated>
<author>
<name>Daniele Varrazzo</name>
<email>daniele.varrazzo@gmail.com</email>
</author>
<published>2012-10-06T00:10:41+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/python-packages/psycopg2.git/commit/?id=fa032f09fb5bdbbb0f804b346978525939261c97'/>
<id>fa032f09fb5bdbbb0f804b346978525939261c97</id>
<content type='text'>
If the network is down, trying to read blocking will hang the process hard
(ctrl-c not working). Send a cancel signal instead (as suggested in
http://archives.postgresql.org/pgsql-hackers/2012-07/msg00903.php) and go
back into a green polling: this should allow a further error (e.g. another
ctrl-c) to break the loop. In this case we cannot assume anything about
the state of the connection, so we close it.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the network is down, trying to read blocking will hang the process hard
(ctrl-c not working). Send a cancel signal instead (as suggested in
http://archives.postgresql.org/pgsql-hackers/2012-07/msg00903.php) and go
back into a green polling: this should allow a further error (e.g. another
ctrl-c) to break the loop. In this case we cannot assume anything about
the state of the connection, so we close it.
</pre>
</div>
</content>
</entry>
</feed>
