MagicStack / MagicStack/asyncpg

Issuing Advisory Lock

Open
#972 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
8.1k
Forks
468
PR merge metrics
No merged PRs in 30d

Description

* **asyncpg version**: 0.25.0
* **PostgreSQL version**: 12.11
* **Do you use a PostgreSQL SaaS? If so, which? Can you reproduce
the issue with a local PostgreSQL install?**:
* **Python version**: 3.9
* **Platform**: Linux
* **Do you use pgbouncer?**: No
* **Did you install asyncpg with pip?**: yes
* **If you built asyncpg locally, which version of Cython did you use?**: No
* **Can the issue be reproduced under both asyncio and
[uvloop](https://github.com/magicstack/uvloop)?**: NA

Receiving this error
```
asyncio.exceptions.TimeoutError
[View similar errors](https://link.datadoghq.com/apm/error-tracking?issueId=...471-da7ad0900002)

Traceback (most recent call last):
File /usr/local/lib/python3.9/site-packages/ddtrace/contrib/asyncpg/patch.py, line 89, in _traced_query
return await method(*args, **kwargs)
File asyncpg/protocol/protocol.pyx, line 338, in query
asyncio.exceptions.TimeoutError
```
Due to internal query call:
`SELECT pg_advisory_unlock_all ( ) CLOSE ALL UNLISTEN * RESET ALL`

Happening quite frequently

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the traceback entry point in asyncpg/protocol/protocol.pyx and the internal query sequence containing SELECT pg_advisory_unlock_all(), CLOSE ALL, UNLISTEN *, and RESET ALL. Reproduce the reported timeout with asyncpg 0.25.0 and PostgreSQL 12.11, then determine the expected behavior and verify that the advisory-lock cleanup no longer times out.

Written by the indexing model from the issue text.

Assessment

Tech stack
postgresql, python
Domain
databases
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.