Re: Psycopg 2.2.x issue with PgBouncer

On Mon, Aug 2, 2010 at 8:21 AM, Marko Kreen <[email protected]> wrote:
> On 8/2/10, Daniele Varrazzo <[email protected]> wrote:

>> =A0I don't know PgBouncer at all so I'm asking Jason -- or whoever can
>> =A0answer: is just the badly-closed connection to be forced out of the
>> =A0pool or is the "unclean server" is serious enough to make it consider
>> =A0the entire pool inconsistent?
>
> Only one connection would be dropped.
>
>> =A0On the base that you can always call rollback() before closing/gc-ing
>> =A0the connection, I'm actually tempted to make the buggy behaviour "a
>> =A0feature".
>
> You seem to forget that it can also call .commit(). =A0And in
> autocommit mode the issue should not even arise, but I'm
> not sure about current code...

No, I just mentioned rollback because this would replicate, from a
data state PoV, what happens to the server both if the client closes
the connection with a straight PQfinish and what used to happen in
psycopg on close()/GC before introducing the bug. commit() would
obviously close the transaction too but replacing close() with
rollback() (or prepending a rollback() call) would keep the semantic
of existing programs untouched, while giving PgBouncer the correct
message.

If this is agreed, I can change the documentation to better explain
what happens on close() and underline the need of closing with a
closed transaction if middleware such as PgBouncer is involved. I'd
like to fix the other issue you mentioned too (infinite loop on error)
before a release.

Jason, can you confirm that adding a rollback() makes your system work
again as expected? Thank you.

-- Daniele