On Tue, 14 Apr 2009 11:51:50 +0200 Morten Brekkevold morten.brekkevold@uninett.no wrote:
Hi all!
As mentioned on the IRC channel before easter week, I've been taking a shot at the deprecate-psycopg1 blueprint (https://blueprints.launchpad.net/nav/+spec/deprecate-psycopg1)
Preliminary results can be found on this branch: http://metanav.uninett.no/hg/features/deprecate-psycopg1/
I would like to merge this code with the default branch as soon as possible. I would like it, though, if people who feel they have some sort of responsibility for code they've written would review the diffs.
Well, for all the recommendations to migrate from the unmaintained psycopg1 branch to psycopg2, we got bit by bugs in psycopg2 pretty quickly.
While using psycopg2, snmptrapd would promptly crash after receiving a trap, issuing a rather strange traceback for a psycopg2.OperationalError. The database connection was lost, and the nav.db API will try to create a new one, but the traceback shows that the OperationalError is seemingly raised in an unrelated part of the code (a line that iterates a list, which has nothing to do with calls to psycopg2).
So I found this psycopg mailing list thread, which basically is a bug report of the same issue, and a confirmation from the psycopg author that it is a bug. The posting is from 2007: http://osdir.com/ml/python.db.psycopg.devel/2007-04/msg00000.html
We're still developing mainly on Debian Etch, which has psycopg2 version 2.0.5 (released in 2006). Testing on our new dev server, which is running Debian Lenny and psycopg 2.0.7, I'm unable to reproduce the bug.
I will try to backport psycopg2 2.0.7 to Etch for time being, but this bug basically will make NAV 3.6 incompatible with Debian Etch (without supplying a psycopg2 backport).