MagicStack / MagicStack/asyncpg

Handle additional InterfaceError types when inside a transaction

Aperta
#956 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Lingua principale
Python
Stelle
8.1k
Fork
468
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Descrizione

* **asyncpg version**: `0.26.0`
* **PostgreSQL version**: `PostgreSQL 14.5 (Debian 14.5-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit` - Also fails on older versions such as PG 13
* **Do you use a PostgreSQL SaaS? If so, which? Can you reproduce
the issue with a local PostgreSQL install?**: Google CloudSQL, but I'm reproducing this locally in a test.
* **Python version**: 3.10
* **Platform**: MacOS
* **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](https://github.com/magicstack/uvloop)?**: yes

When an InterfaceError is raised during a transaction, `asyncpg` does not explicitly handle all variants of this exception, and raises it.

https://github.com/MagicStack/asyncpg/blob/5f908e679a6264c5fcf8a92895a2f34a9387e4da/asyncpg/transaction.py#L65-L79

For example, it does not handle the type `asyncpg.exceptions.ConnectionDoesNotExistError` - and as such, this leads to leftover connections while trying to close the pool. Simple reproduction that forces the error by setting `idle_in_transaction_session_timeout` to be very small - basically telling the server to close a connection before it can complete a query:

```python
pool = await asyncpg.create_pool(
dsn=dsn,
min_size=1,
max_size=4,
server_settings={
"idle_in_transaction_session_timeout": "1",
},
)

async def query_gen():
async with pool.acquire(timeout=5) as con:
async with con.transaction(readonly=True):
await con.fetch(
"SELECT * FROM my_db.my_schema.my_table;", timeout=15
)

tasks = []
for i in range(40):
tasks.append(query_gen())
results = await asyncio.gather(*tasks, return_exceptions=True)

print(results, flush=True)

await pool.close()
```

The `results` List is all exceptions:
```
[InterfaceError('cannot call Transaction.__aexit__(): the underlying connection is closed'), InterfaceError('cannot call Transaction.__aexit__(): the underlying connection is closed'), InterfaceError('cannot call Transaction.__aexit__(): the underlying connection is closed'), InterfaceError('cannot call Transaction.__aexit__(): the underlying connection is closed'), ...]
```

The exception type is `asyncpg.exceptions.ConnectionDoesNotExistError`. And the `pool.close()` will print a warning:
```
asyncpg.pool:Pool.close() is taking over 60 seconds to complete. Check if you have any unreleased connections left. Use asyncio.wait_for() to set a timeout for Pool.close().
```

When this happens, I do believe the connection pool should set the `_in_use` attribute for the connection holder to `False` and / or delete the pool connection holder.

This does not happen when not using the `async with con.transaction()` context manager.

Note: Under normal conditions / default settings, I see this rarely, however, I do see the `pool.close()` warning on occasion.

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Direzione di ricerca

Inizia in asyncpg/transaction.py alle righe collegate 65-79, quindi esegui la riproduzione asyncio fornita con idle_in_transaction_session_timeout impostato su 1. Traccia l’effetto di ConnectionDoesNotExistError durante la transazione sul pool e verifica che la connessione venga rilasciata e che pool.close() venga completato senza l’avviso relativo alla connessione non rilasciata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
postgresql, python
Ambito
database
Tipo di issue
Bug
Difficoltà
3/5
Tempo stimato
1-2 giorni
Stato di attività
Ferma
Chiarezza
Abbastanza chiara
Idoneità per principianti
38/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.