MagicStack / MagicStack/asyncpg
Pool created with min_size loses inactive connections and never re-acquires them
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- Python
- Estrellas
- 8.1k
- Forks
- 468
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Descripción
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.
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Comienza en asyncpg.create_pool e inspecciona cómo interactúa max_inactive_connection_lifetime con min_size cuando se cierran las conexiones inactivas. Reproduce el problema con el sleep proporcionado y las comprobaciones de pool.get_size(). Se considera terminado cuando un pool configurado con min_size conserva o vuelve a adquirir ese mínimo después de que las conexiones inactivas agoten su tiempo de espera.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- postgresql, python
- Área
- databases
- Tipo de issue
- Error
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Estado de actividad
- Estancado
- Claridad
- Bastante claro
- Aptitud para principiantes
- 45/100