I tried with d13f8ff and got this: https://gist.github.com/1354828

IOW, when trying a nonexistent table, an error is reported and when using a wrong password a traceback appears.

The reason you get a traceback is that you should explicitly close() the connection that you opened. Adding

d.addErrback(lambda _: conn.close())

just before

d.addBoth(lambda _: reactor.stop())

makes the traceback go away for me.

The weird thing is that you seem to be getting a traceback with both configurations.

from txpostgres.

Ah, just saw something and gave it a try... and bingo. Using the select reactor gives me a traceback both of the times. Thank you @oberstet for the test case, I'll have to investigate by select behaves different than poll (which is the default on Linux)

from txpostgres.

ah, ok.

here are my results (FreeBSD):

b) bad password

the problem goes away when adding the

d.addErrback(lambda _: conn.close())

for both using select reactor or new kqueue reactor.

Ok, however I'm wondering: this seems to be different from what I do with standard adapi

https://github.com/oberstet/txpostgres/blob/testing/testing/adbapi_error.py

which is happy without the close. Is this related to the asynch. connection establishment?

a) nonexistent table

select() reactor: problem THERE
poll() reactor: problem NOT there
new kqueue() reactor: problem NOT there

with FreeBSD, the select reactor is default .. currently.

from txpostgres.

OK, this one is as tricky as they come.

The chain of events is:

• Postgres finishes the authentication process, sends the OK over the wire
• the specialised doRead gets called on the connection object
• base PollingMixin's doRead gets called, gets POLL_OK
• the Deferred returned from connect() callbacks
• the connection starts watching the socket for notifies
• a cursor is created and runs a query
• the cursor tells the connection to stop watching the connection sends the query to the server, adds itself as a reader for the socket
• the call to base doRead returns (sic!) and the connection checks for notifies and starts watching the socket
• doRead is called on the connection which calls poll(), which raises a "nonexistent table" exception
• the connection has no current Deferred, so it reraises the exception and boom, Unhandled error

So in fact this is a reentrancy issue with cursorRunning/cursorFinished, kind of. Let me think about how to handle this...

from txpostgres.

I think the issue is solved (at least in my testing I consistently got correct results - no tracebacks).

Thanks for the report!

from txpostgres.

Perfect!

Just tested select(), poll() and new kqueue() reactor on FreeBSD .. all 3 work with both test examples! Identical behavior.

Thanks alot for nailing down this tricky stuff;)

Tobias

from txpostgres.

Thanks, the patch is identical to what I've had in my queue for 'recursion depth exceeded' exception under heavy load!

from txpostgres.