Add support for sqlrelay backend, to pool DB connections

[dustin@…]

A ​discussion in the mailing list led to sqlrelay as being a good solution to limiting DB connections coming out of Django (among other benefits). I didn't see any activity over here, so I figured I'd open a ticket.

[hugo]

first take at an sqlrelay backend for postgresql

[hugo]

I added a first take at a SQLRelay backend for Django, using the PostgreSQL database. This is actually needed per database, as SQLRelay will only handle some outer syntax itself (like using allways either :xxx or ? parameter style), but won't interfer with the SQL syntax itself. So sqlrelay actually is just another database driver for every database supported.

I did first tests with it and the basic stuff seems to work, but I do get weird hangups in sqlrelay. And if sqlrelay doesn't respond any more, the sqlrelay client libraries really go bozo - they took up a gigabyte of memory within only a few minutes. Don't know what exactly happened, as the sqlrelay debug logs are anything than helpfull (they just stop logging at one point in time, no mentioning what actually happens), but regardless of what did go wrong, they shouldn't eat up memory like they do. Even if I did configure the beast wrong, it shouldn't kill the machine.

So I am actually not that motivated to do more work on this, but attach the file nonetheless, so somebody else can take over from here.

Some caveat: postgresql connections start out with autocommit, that's why I send the BEGIN statement as the first statement, to switch them to transaction control (most postgresql drivers do that themselves, the sqlrelay driver doesn't). I used the DBAPI compliant sqlrelay driver, maybe better results and greater control could be gained by using the sqlrelay native API. Most work done was just setting up a wrapper for the cursor to turn parameter style into something sqlrelay requires. Otherwise it's just a copy of the postgresql driver with the type registry thrown out - maybe we would need additional code for handling datetime field types. Can't say myself, as I never reached a state where I could successfully play with those.

[Adrian Holovaty]

Closing because we don't need this at the moment.

[Aymeric Augustin]

TicketClosingReasons/DontReopenTickets

This is better handled by external tools such as pgpool.