Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#122 MySQL 4.1 returns bizarre result set

MySQLdb-1.1
closed
Andy Dustman
MySQLdb (285)
5
2012-09-19
2005-01-12
Mike Verdone
No

Hi again,

We're having another problem with MySQL 4.1 which may
or may not be related to mysql-python. I'll post as
much detail as I can.

MySQL 4.1.8
MySQL-python 1.1.8
Python 2.2.2
Red Hat 7.2 and 7.3

We can't make the problem reoccur reliably. I am sure
the problem is happening at the C level since I can
make it happen with only the _mysql library.

The problem is that we're getting a bad resultset
from a query. The query will be a simple "SELECT foo
FROM bar" and a result will come back, but doing
result.describe() shows all the field names as '\x0'
and the type IDs are messed up and don't map to any
types in the conv dict. It looks like the resultset
is bad by the time it's passed to
_ResultSet_initialize.

We can only make this happen on RH 7.2 and 7.3
systems, it works fine on more recent distros. As
well we can't make it happen reliably.

In some other cases we are getting errors about
tables not existing which then show that the
connection is using the wrong database. We have
multiple connections open to the same database, and
it almost seems like select_db on one connection is
affecting the other connection.

This problem may exist in the MySQL 4.1 C libraries
(we have opened a support ticket with them), but I'm
wondering if you've ever seen anything like this
before.

Thanks.

Discussion

  • Andy Dustman
    Andy Dustman
    2005-01-12

    Logged In: YES
    user_id=71372

    Would it be possible to try Python-2.3 or 2.4 on one of
    those systems?

    You aren't trying to share connections between threads, are
    you? That's generally a lot more trouble than it's worth.

    You must be using the MySQL.com RPM packages, I expect. It
    looks like some of their packages (not just RPMs) are linked
    against glibc-2.2 and others against glibc-2.3, and it isn't
    clear what the RPMs use, but I think they are
    statically-linked anyway. RH 7.x uses glibc-2.2.

    Another thing to try is getting their source RPM and
    rebuilding that, and installing the resulting binary packages.

    I tend to doubt this has anything to do with MySQLdb,
    though, based on your description, but report back on your
    findings.

    (Apparenly 1.1.x does work on Python-2.2; I have not done
    any testing with 2.2.)

     
  • Mike Verdone
    Mike Verdone
    2005-01-13

    Logged In: YES
    user_id=1186966

    Yeah, I'm thinking it's a glibc or other library problem.
    Building MySQL from source would be a good thing to do.
    Unfortunately I can't spend any more time on this. The
    decision was made to revert back to MySQL 4.0 for our
    application since this upgrade is turning out to be a
    major headache. (Though of course we'll have to upgrade
    eventually and then the problems may be worse... ah, the
    joy of maintenance).

    If I learn anything more about the problem I'll come back
    and leave a comment here, but until then I'll mark this
    closed since it's probably not a mysql-python bug.

    Thanks!