MagicStack / MagicStack/asyncpg
[Bug] Wrong number of columns Error
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 8.1k
- Forks
- 468
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
- asyncpg version: 0.23
- PostgreSQL version: 13
- Do you use a PostgreSQL SaaS? If so, which? Can you reproduce
the issue with a local PostgreSQL install?: Yandex Cloud - Python version: 3.7
- Platform: Ubuntu 18.04
- Do you use pgbouncer?: yes
- Did you install asyncpg with pip?: no
- If you built asyncpg locally, which version of Cython did you use?: no
- Can the issue be reproduced under both asyncio and
uvloop?: don't know
We have a web server on Python which is sending queries to the PostgreSQL cluster. After adding a column to the table using a migration without disconnecting I encounter errors with some queries to that table. Example of the query below:
WITH row_info as ( SELECT id FROM UNNEST($1::scheme.affected_table[]) ) DELETE FROM scheme.affected_table AS entities USING row_info WHERE entities.id = row_info.id;
To $1 I pass the list of dictionaries like [{'id': 1, 'field1': 'value1', ...}].
Before the migration or from new connections the query works perfectly. But for queries from web-server I get "wrong number of columns: 11, expected 12". Rebooting the web-server resolves the problem.
I think the problem can be related to Prepared Statements or encoding of Mapping.
Guide de contribution
Aucun guide de contribution indexé pour ce dépôt
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Le rapport ne fournit aucun fichier source ni point d’entrée de test. Commencez par reproduire la requête UNNEST après une migration de schéma avec une connexion existante, puis comparez-la avec une nouvelle connexion tout en examinant les instructions préparées et l’encodage du mapping. C’est terminé lorsque la requête utilisant la connexion obsolète ne signale plus de différence dans le nombre de colonnes.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- postgresql, python
- Domaine
- databases
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 30/100