MagicStack / MagicStack/asyncpg
Pool created with min_size loses inactive connections and never re-acquires them
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
I love asyncpg, been using it for years. However recently came across some unexpected behavior with v 0.30.0. It goes a little something like this.
Initialize a pool with a min_size:
import asyncio
import asyncpg
pool = await asyncpg.create_pool(min_size=10, max_size=20, **kwargs) # assume kwargs has connection info
print(f'Total: {pool.get_size()}')
# Total: 10
All good. But now let's say that nothing happens for over 5 minutes. You know, because max_inactive_connection_lifetime=300.0 by default. And check again:
await asyncio.sleep(305)
print(f'Total: {pool.get_size()}')
# Total: 0
Huh? Why isn't it still 10? No matter what I set for max_inactive_connection_lifetime this behavior happens immediately after that time, as long as the time is non-zero. If it's set to 0 then the behavior correctly doesn't happen.
I don't know if this is intentional or not, but as a developer, when I open a database pool with a minimum number of connections I expect that the pool will maintain that minimum, even if they are automatically closed or timeout.
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
Commencez par asyncpg.create_pool et examinez comment max_inactive_connection_lifetime interagit avec min_size lorsque les connexions inactives sont fermées. Reproduisez le problème avec le sleep fourni et les vérifications de pool.get_size(). Le travail est terminé lorsqu’un pool configuré avec min_size conserve ou réacquiert ce minimum après l’expiration du délai des connexions inactives.
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é
- 3/5
- Temps estimé
- 1-2 jours
- Activité
- À l'abandon
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100