MagicStack / MagicStack/asyncpg
Intermittent no pg_hba.conf entry for host
Chưa có ai nhận issue này.
- Ngôn ngữ chính
- Python
- Star
- 8.1k
- Fork
- 468
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Mô tả
I have a long-running script which initializes an asyncpg.Pool at the start of the script, then spawns a ton of tasks on an eventloop which occasionally acquire a connection, write something and put the connection back. An individual connection could in theory go a long time between usages, since the writes are only occasional. Plenty of time for some of them to idle out. That may be relevant here, because exactly every ten minutes, I get a few errors like this in my task log:
asyncpg.exceptions.InvalidAuthorizationSpecificationError: no pg_hba.conf entry for host
The script goes through its recovery logic, throwing away of bunch of work that the task already did, and the script resumes working again. The connections continue working again for another 10 minutes - plenty of writes get through, so this is not really an auth error - then the cycle repeats.
This feels like asyncpg acquires a connection which is invalidated in some way, then raises when it checks the connection but before passing it along. I am not sure why the connections are invalidated, but the extreme regularity of it implies that the connections failed a keepalive or idled out and asyncpg doesn't account for the possibility in the acquire logic. It's also very possible that I have initialized the pool incorrectly and I'm seeing expected behavior. My pool's connection settings are all default. The connection is directly to PG, no middleware.
PostgreSQL 15.10 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0, 64-bit
asyncpg 0.30.0
Here is what I believe is the relevant part of the stack trace. All stack frames above this are my own code and the exception is thrown on a async with pool.acquire() as conn: line.
Am I running into expected behavior?
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 864, in _acquire
return await _acquire_impl()
^^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 849, in _acquire_impl
proxy = await ch.acquire() # type: PoolConnectionProxy
^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 140, in acquire
await self.connect()
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 132, in connect
self._con = await self._pool._get_new_connection()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/pool.py", line 517, in _get_new_connection
con = await self._connect(
^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/connection.py", line 2421, in connect
return await connect_utils._connect(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/connect_utils.py", line 1049, in _connect
conn = await _connect_addr(
^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/connect_utils.py", line 891, in _connect_addr
return await __connect_addr(params_retry, False, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/redacted/miniconda3/envs/redacted/lib/python3.12/site-packages/asyncpg/connect_utils.py", line 934, in __connect_addr
await connected
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Hướng nghiên cứu
Bắt đầu với asyncpg/pool.py tại _acquire, PoolConnectionHolder.acquire và _get_new_connection, sau đó lần theo asyncpg/connect_utils.py đến __connect_addr bằng stack trace được cung cấp. Tái hiện lỗi xảy ra lặp lại với PostgreSQL 15.10 và asyncpg 0.30.0, đồng thời xác định liệu việc acquire từ pool có xử lý lỗi kết nối được báo cáo như mong đợi hay không; được xem là hoàn thành khi hành vi và mọi thay đổi cần thiết được xác lập rõ ràng bằng một regression test nếu phù hợp.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- postgresql, python
- Lĩnh vực
- databases
- Loại issue
- Lỗi
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức độ hoạt động
- Đình trệ
- Độ rõ ràng
- Cần làm rõ
- Mức phù hợp với người mới
- 25/100