Skip to content

Asyncpg sensitive to build info in version number #261

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mumbleskates opened this issue Feb 14, 2018 · 1 comment
Closed

Asyncpg sensitive to build info in version number #261

mumbleskates opened this issue Feb 14, 2018 · 1 comment

Comments

@mumbleskates
Copy link

mumbleskates commented Feb 14, 2018

  • asyncpg version:
    0.14.0

  • PostgreSQL version:
    Many pg10 versions with extra build/variant version info. For example, the current docker latest image for 10.2: https://github.com/docker-library/postgres/blob/674466e0d47517f4e05ec2025ae996e71b26cae9/10/Dockerfile

  • Do you use a PostgreSQL SaaS? If so, which? Can you reproduce
    the issue with a local PostgreSQL install?
    :
    This is easily reproducible with a local PostgreSQL install, either using the docker image linked above or by installing the standard repository version from ubuntu 18.04 (reproduced with 10.2-1 from repository http://us.archive.ubuntu.com/ubuntu bionic/main amd64).

  • Python version:
    3.6.4

  • Platform:
    intel amd64 ubuntu 18.04 in vmware, linode amd64 ubuntu 16.04

  • Do you use pgbouncer?:
    No

  • Did you install asyncpg with pip?:
    Yes

  • If you built asyncpg locally, which version of Cython did you use?:
    n/a

  • Can the issue be reproduced under both asyncio and
    uvloop?
    :
    Yes

Whenever a connection is established to the server, the server version string goes through overly stringent parsing that will break if anything remotely unexpected appears in the version string. Several new versions of postgres server I have encountered include build information in parentheses after the numeric version. For example, a real value encountered: '10.2 (Ubuntu 10.2-1)'.

This will cause errors like the following:

ValueError: invalid literal for int() with base 10: '2 (Ubuntu 10'

ValueError: invalid literal for int() with base 10: '2 (Debian 10'

...at line serverversion.py:46, versions = [int(p) for p in parts][:3], in split_server_version_string().

Tiptoeing around this strange restriction by installing from very specific repositories and build versions is becoming cumbersome in CI configuration and deployment, where a minor upgrade to a newer, stable-channel version of postgres server completely breaks Asyncpg's ability to connect to it.

@mumbleskates
Copy link
Author

My apologies: #250 05dce25

Natrinicle added a commit to Natrinicle/asyncpg that referenced this issue Jun 25, 2021
MagicStack#250
MagicStack#261
MagicStack#771

Just tried to use this library through Ormar->Databases->AsyncPG against
a Yugabyte cluster and hit issue 771. Looks like this has been a problem
for a while now so going for a complete overhaul of the server version
extraction method. Using a groupdict regex against the version string
allows for much higher flexibility in extracting what we're looking for
and fixes 771 while not breaking any of the existing version patterns.
elprans pushed a commit that referenced this issue Aug 2, 2021
#250
#261
#771

Just tried to use this library through Ormar->Databases->AsyncPG against
a Yugabyte cluster and hit issue 771. Looks like this has been a problem
for a while now so going for a complete overhaul of the server version
extraction method. Using a groupdict regex against the version string
allows for much higher flexibility in extracting what we're looking for
and fixes #771 while not breaking any of the existing version patterns.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant